[systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media

[Kok, Auke-jan H]

On Sat, Mar 23, 2013 at 4:37 PM, Kay Sievers <kay at vrfy.org> wrote:
> On Sun, Mar 24, 2013 at 12:02 AM, Kok, Auke-jan H
> <auke-jan.h.kok at intel.com> wrote:
>> On Sat, Mar 23, 2013 at 3:54 PM, Kay Sievers <kay at vrfy.org> wrote:
>>> On Sat, Mar 23, 2013 at 11:47 PM, Lennart Poettering
>>> <lennart at poettering.net> wrote:
>>>> On Sat, 23.03.13 23:42, Tom Gundersen (teg at jklm.no) wrote:
>>>>
>>>>>
>>>>> On Sat, Mar 23, 2013 at 2:16 AM, Lennart Poettering
>>>>> <lennart at poettering.net> wrote:
>>>>> > Then, I generally believe better than trying to be smart when reading
>>>>> > things we should much rather try to place things properly on disk. We
>>>>> > already defrag things based on the read order for btrfs, we should do
>>>>> > the same for ext4. The API for that unfortunately awful, but e4rat has
>>>>> > shown that this does work. Basically, this is what you do:
>>>>>
>>>>> Isn't the problem that reads by blkid and friends are not being caught
>>>>> by readahead-collect, and hence end up blocking until readahead-replay
>>>>> has finished? In that case reordering won't help (I think).
>>>>
>>>> Hmm, if root file system is mounted the file system's superblock should
>>>> be cached in memory, I'd expect, so blkid shouldn't have to block...
>>>
>>> I guess it's more about ~30-40 tiny seek()/read() on the main block
>>> device, spread all over the place mainly the first 200 and the last
>>> few kilobyte of the disk, what blkid need to do.
>>>
>>> None of of that shares the cache with the mounted filesystem blocks,
>>> and I don't think any of that data is in any other cache at that time.
>>
>> I don't see anything in udev code setting IOPRIO... perhaps elevating
>> the few calls doing bklid and mount might be helpful?
>
> Maybe that really makes a difference, we should definitely try that.
> The blkid calls are really limited to a few bytes here and there, and
> will never loop for a long time, so that should be fine.
>
> Do you have a box, where you could you give it a quick try to bump the
> prio for the libblkid calls:
>   ioprio_set(IOPRIO_WHO_PROCESS, getpid(), ...)
> in:
>   src/udev/udev-builtin-blkid.c
> ?

I left my non-ssd dev box in the office, so it'll be monday - but I'll
absolutely give it a good test run.

Auke