From: Nick Piggin <piggin@cyberone.com.au>
To: Randy Appleton <rappleto@nmu.edu>
Cc: Bill Davidsen <davidsen@tmr.com>, linux-kernel@vger.kernel.org
Subject: Re: Unneeded Code Found??
Date: Mon, 19 Jan 2004 16:54:08 +1100 [thread overview]
Message-ID: <400B7100.7090600@cyberone.com.au> (raw)
In-Reply-To: <400B2BCF.7090003@nmu.edu>
Randy Appleton wrote:
> Bill Davidsen wrote:
>
>> Randy Appleton wrote:
>>
>>> I think I have found some useless code in the Linux kernel
>>> in the block request functions.
>>>
>>>
>>> I have modified the __make_request function in ll_rw_blk.c.
>>> Now every request for a block off the hard drive is logged.
>>>
>>>
>>> The function __make_request has code to attempt to merge the current
>>> block request with some contigious existing request for better
>>> performance. This merge function keeps a one-entry cache pointing to
>>> the
>>> last block request made. An attempt is made to merge the current
>>> request with the last request, and if that is not possible then
>>> a search of the whole queue is done, looking at merger possibililites.
>>>
>>>
>>> Looking at the data from my logs, I notice that over 50% of all
>>> requests
>>> can be merged. However, a merge only ever happens between the
>>> current request and the previous one. It never happens between the
>>> current request and any other request that might be in the queue (for
>>> more than 50,000 requests examined).
>>>
>>>
>>> This is true for several test runs, including "daily usage" and doing
>>> two kernel compiles at the same time. I have only tested on a
>>> single-CPU machine.
>>>
>>>
>>> I wonder if the code (and CPU time) used to search the entire request
>>> queue is actually useful. Would this be a reasonable candidate for
>>> code
>>> elimination?
>>
>>
>>
>> If you never get a hit, it means either (a) your test load actually
>> doesn't have one, or (b) the code isn't correctly finding them.
>
>
>
> It might be buggy code on my part, but it looks pretty solid to me.
> I'd be happy to show anyone interested.
> My load ought to find such a merge, if they happen with any freqency
> at all. Compiling two kernels
> at the same time and "general running" are my two current loads. The
> disk queue gets to over 70
> entries, which is rather high for a personal workstation, and I'm
> searching tens of thousands to accesses
> in total.
>
> Does anyone know that this code is actualy useful? Has anyone ever
> seen it actually do a merge of consecutive
> data accesses for requests that were not issued themselves consequtively?
>
Yes it gets used.
I think its a lot more common with direct io and when you have lots of
processes.
next prev parent reply other threads:[~2004-01-19 5:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-09 23:28 Unneeded Code Found?? Randy Appleton
2004-01-15 16:02 ` Bill Davidsen
2004-01-19 0:58 ` Randy Appleton
2004-01-19 0:30 ` Mike Fedyk
2004-01-19 5:54 ` Nick Piggin [this message]
2004-01-23 22:23 ` Randy Appleton
2004-01-24 0:00 ` Nick Piggin
2004-01-25 22:36 ` Randy Appleton
2004-01-23 22:10 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=400B7100.7090600@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rappleto@nmu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.