Raspberry Pi: Reclaim ~1% CPU Usage when SSD/USB Booting

Native support for USB mass storage device booting has made it’s way to all of the Raspberry Pi 4’s firmware release channels! With that exciting development an old issue from the Pi 3 and earlier USB booting days has manifested itself once again in the form of a constant 1-2% CPU draw even with nothing running.

This guide will show you an easy config.txt parameter to eliminate this problem and optimize your mass storage boot setups!

Equipment Used

StarTech 2.5" SATA to USB 3.0/3.1 Adapter
StarTech 2.5″ SATA to USB 3.1 Adapter

The USB 3.1 variant of the StarTech 2.5″ SATA adapter works well with the Pi 4. The USB 3.0 variant doesn’t have firmware updates available and is not recommended.

Links: Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.jp*, Amazon.co.uk*, Amazon.de*, Amazon.es*, Amazon.fr*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*, Amazon.sg*

Kingston A400 SSD
Kingston A400 2.5″ SATA SSD

The Kingston A400 has been a great drive to use with the Pi for years. It’s reliable, widely available around the world, has low power requirements and performs very well. It’s also very affordable. This drive has been benchmarked over 1000 times at pibenchmarks.com and is the #1 most popular SSD among the Pi community!

Links: AliExpress*, Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.jp*, Amazon.co.uk*, Amazon.de*, Amazon.es*, Amazon.fr*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*, Amazon.sg*

Why it happens

The Raspberry Pi polls endlessly for a SD card to be inserted if there is not a SD card in the slot. It polls so quickly that it actually registers as CPU usage on your system. You can observe this if you write an image to a SD card and look at the idle CPU usage and then put the same image on a SSD. On there you will notice a constant ~1% CPU drain:

Raspberry Pi SD Polling Processes
Top command running on Ubuntu booted on a USB mass storage device (SSD)

Notice the mystery rcu_preempt process using 0.7% CPU? That is the SD card polling. The exact name of the process can vary depending on which OS and version you are running but it will never be an application and will always be a generic system background process. There is absolutely nothing running on this machine other than my “top” command, which actually came in second in CPU usage to this process. This is wasting your CPU cycles!

You can actually test that this is indeed the SD card slot polling yourself. Look what happens once we put a SD card in the slot:

Raspberry Pi SD Polling Processes without SD Card
Top command after inserting SD card into SD card slot

Now we have a completely clean “top” where the only thing on the system consuming CPU cycles is the top application itself!

It doesn’t matter if the SD card is blank or not or what is on there, just that you put it in there. This will cause the polling to stop and free your CPU again. If you take it out the CPU usage will immediately return!

You may see the rcu_preempt still fire up and consume CPU cycles from time to time. That’s okay, it is taking care of other tasks than just SD polling, but the constant 0.7-1% CPU usage drain will disappear!

Fixing SD card polling with config.txt

Fortunately there is a more permanent / better way to fix this issue without having to put a SD card in the slot to do nothing! The solution is to add a parameter to your config.txt file (/boot/config.txt on Raspberry Pi OS, /boot/firmware/config.txt on Ubuntu) to instruct the Pi not to continuously check for a SD card to be inserted and instead to poll just once (upon startup). The parameter to add to your /boot/config.txt file is:


Now restart your Pi. Even without a SD card inserted your CPU usage will be back to normal!

Old method

There was an older parameter for changing this that used to be used on the Raspberry Pi 3 and older. This was:


This syntax has been obsoleted and no longer works on the Pi 4. I figured I would put it here though to eliminate confusion and in case anyone is running a really old OS and needs it or is trying to search for this looking for the updated syntax.

Benchmarking / Testing Storage

If you want to verify your drive’s performance you may want to run my storage benchmark with:

sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash

If you search for the model of your drive on pibenchmarks.com you can compare your score with others and make sure the drive is performing correctly!

Other Resources

To find out where to get the 64 bit version of Raspberry Pi OS: where to get the 64 bit Raspberry Pi OS image

If you’re looking for help setting up USB mass storage booting on your Pi check out my new Raspberry Pi 4 Bootloader USB mass storage booting guide

If you’re having trouble with your bootloader or firmware on your Pi check out my firmware / restore guide here

You may also want to check out the Raspberry Pi benchmarks or even run the benchmark yourself at https://pibenchmarks.com/

Notify of

Inline Feedbacks
View all comments
3 years ago

I added a line dtparam=sd_poll_once under the [pi4] section in /boot/firmware/config.txt (Ubuntu 20.04), updated system and rebooted. But if I do: top -p pidof rcu_preempt the rcu_preempt process is still sitting there, with 0.0% CPU which briefly goes up to 0.3% every 5 seconds or so. Is this the expected result?

3 years ago

So I made another test: I made a new fresh Ubuntu 20.04 setup on my SSD (thanks for the guide btw!) and I took a look again at the rcu_preempt process without changing anything. The process was there but 0% CPU, didn’t even go up to 0.3% as before. I put an SD card while running top, and no behavior change..