Well, pulled some bucks and got a new 240GB SSD, dropped it in my T470, no biggy, just follow the standard procedure (do turn off the internal battery before any change, check the videos to dissamble the laptop without breaking any plastic thingy).

I deployed a new Ubuntu 18.04 in it, and wanted to let it well configured for the new disk, so, I reviewed a couple of articles.

I’m using an old BIOS version, 1.28 (in Ubuntu 18.04, checked it with hardinfo > apt install hardinfo), it’s working really well, nothing breaks in my daily use, nothing to touch there. Also, everything is enabled in the BIOS (bluetooth, thunderbolt, etc.), I’m commenting this because..(go to the end of the text, thnks).

With the SSD deployed, EVERYTHING worked just fine, super-fast, but I remembered about the TRIM stuff and got to discover a couple of additional low writing to disk configs, so the game began :-D

Hardware specs: Intel Corei5 7300U, 8 GB RAM, 240 GB SSD

I wanted to test and check if I could make the laptop work faster (spoiler: I did it!), so lets get to business:

1) Deployed new low latency stable kernel 4.17.1

from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.1/

Download these files to a directory with no other .deb files, then do a “sudo dpkg -i *.deb”

This kernel is newer than the latest 4.15.x deployed by U18.04 so it should boot by default.

2) Weekly TRIM in cron

a. Check for TRIM support in the disk:

Try lsblk -D , TRIM/discard is available, if the DISC-MAX column is not 0B

Example (SSD/trim available)

[root@foo bar]# lsblk -D
sda 0 4K 1G 0

Example (HDD/trim not available)

[root@foo bar]# lsblk -D
sda 0 0B 0B 0

b. Enable TRIM in the system

sudo gedit /etc/cron.weekly/fstrim

add these lines:

/sbin/fstrim — all || true

make it runable:

sudo chmod +x /etc/cron.weekly/fstrim

3) Grub: disable disk queues for the SSD

* Explained here

sudo gedit /etc/default/grub

look for GRUB_CMDLINE_LINUX=””, change it to:



sudo update-grub

4) /etc/fstab

a. Applied some low writing to disk parameters for /

Changed from the original:

UUID=XXXXXX / ext4 errors=remount-ro 0 1


UUID=XXXXXX / ext4 noatime,nodelalloc,barrier=0,i_version,commit=30,inode_readahead_blks=64,errors=remount-ro 0 1

b. Configured tmpfs filesystem for /tmp and /var/tmp

tmpfs /tmp tmpfs noatime,nodiratime,nodev,nosuid,mode=1777,size=1G,defaults 0 0
tmpfs /var/tmp tmpfs noatime,nodiratime,nodev,nosuid,mode=1777,size=1G,defaults 0 0

About “size=1G”, if you don’t limit the tmpfs filesystems with this parameter it will “use” half of the available ram, but, will not “reserve it”, you can still use it, but the tmpfs filesystem COULD get to use half the ram if something goes south. So I just limited it both mount points, and checked more or less regularly against my current use pattern (df -h in a CLI), and 1GB worked well.

5) Sysctl

Edit /etc/sysctl.conf, add these lines at the end of the file (it will be active after a reboot)


6) /etc/xdg/autostart

The files in this directory are executed by the xsession scripts in /etc/X11, if you look into them, you’ll find that some of them are meant to only run in certain graphical interfaces (Gnome yes, KDE no). But some components — mainly from Gnome — are used in KDE too, actually they run, but some people never get to use them, so

This configuration is tunned for KDE, deleted a couple of things (FIRST make a copy of /etc/xdg/autostart), related to Gnome 3 / New Ubuntu GUI / maybe XFCE4 (so you probably don’t want to delete them if you don’t use KDE).

Some do not actually run anything (the first use stuff), but certainly got executed by the xsession script, losing some precious ms; other stuff has no use for me particularly, kconnectd (send/receive files/notifications from android phones in KDE), blueman (bluetooth something), at-spi-dbus (support for accesibility), spice-vdagent (useful to access KVM virtual machines), dejadup monitor (backup for end-users), etc.


7) TLP

Tried this because everyone is reporting it to be really useful to just deploy it and then you recover a couple of minutes (even 10 to 20 min., depending on your use style for the laptop > 50% brightness is different from 100%),

apt install tlp

Didn’t install tp-smapi-dkms (it’s explained in the arch wiki: it’s no useful for anything after the T*30 series, other driver already present is used)

For the guys who want to limit charge thresholds, you can check /etc/default/tlp

# Battery charge thresholds (ThinkPad only, tp-smapi or acpi-call kernel module
# required). Charging starts when the remaining capacity falls below the
# START_CHARGE_THRESH value and stops when exceeding the STOP_CHARGE_THRESH value.
# Main / Internal battery (values in %)


# Ultrabay / Slice / Replaceable battery (values in %)

8) Preload

apt install preload

This software is actually meant to auto-tune itself, but it has a config file in /etc/default/preload, and there I found this option to low the disk use and unchecked it (then restarted preload with “systemctl restart preload”):

# Enabling this should lead to lower disk activity.
OPTIONS=”-l /dev/null”

9) Disabling unnecessary Systemd services

systemctl disable mpd.socket
systemctl disable snapd
systemctl disable avahi-daemon
systemctl disable apparmor
systemctl disable ModemManager
systemctl mask ModemManager
systemctl disable NetworkManager-wait-online
systemctl mask NetworkManager-wait-online
systemctl disable nmbd
systemctl disable smbd
systemctl disable ssh
systemctl disable lm-sensors
systemctl mask lm-sensors
systemctl mask apparmor
systemctl mask bluetooth
systemctl mask speech-dispatcher
systemctl mask pppd-dns
systemctl mask accounts-daemon
systemctl mask apport

“NetworkManager-wait-online” took close to 9 secs. to finish, wow.

You can check how performs your Ubuntu with

a. systemd-analyze time

I got this from the former:

Startup finished in 4.134s (firmware) + 3.996s (loader) + 3.712s (kernel) + 3.527s (userspace) = 15.371s
graphical.target reached after 2.254s in userspace

systemd-analyze blame

And this output from “blame” (I think TLP could be started from the desktop, after it’s been loaded, it is just a “tlp start” from a script).

1.280s tlp.service
858ms dev-sda2.device
675ms dev-loop8.device
672ms dev-loop9.device
669ms dev-loop10.device
665ms dev-loop12.device
664ms dev-loop11.device
616ms networkd-dispatcher.service
588ms systemd-journal-flush.service
583ms udisks2.service
577ms dev-loop7.device
539ms dev-loop4.device
528ms dev-loop5.device
527ms dev-loop2.device
524ms dev-loop3.device
524ms dev-loop6.device
494ms dev-loop0.device
473ms dev-loop1.device
377ms systemd-resolved.service
355ms NetworkManager.service
332ms networking.service

Source (spanish)

More From Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade