From: Nick Piggin <nickpiggin@yahoo.com.au>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: "'Jens Axboe'" <axboe@suse.de>,
Claudio Martins <ctpm@rnl.ist.utl.pt>,
Andrew Morton <akpm@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
Neil Brown <neilb@cse.unsw.edu.au>
Subject: Re: Processes stuck on D state on Dual Opteron
Date: Tue, 12 Apr 2005 21:09:09 +1000 [thread overview]
Message-ID: <425BAC55.7020506@yahoo.com.au> (raw)
In-Reply-To: <200504120803.j3C83tg06634@unix-os.sc.intel.com>
Chen, Kenneth W wrote:
> On Tue, Apr 12 2005, Nick Piggin wrote:
>
>>Actually the patches I have sent you do fix real bugs, but they also
>>make the block layer less likely to recurse into page reclaim, so it
>>may be eg. hiding the problem that Neil's patch fixes.
>
>
> Jens Axboe wrote on Tuesday, April 12, 2005 12:08 AM
>
>>Can you push those to Andrew? I'm quite happy with the way they turned
>>out. It would be nice if Ken would bench 2.6.12-rc2 with and without
>>those patches.
>
>
>
> I like the patch a lot and already did bench it on our db setup. However,
> I'm seeing a negative regression compare to a very very crappy patch (see
> attached, you can laugh at me for doing things like that :-).
>
OK - if we go that way, perhaps the following patch may be the
way to do it.
> My first reaction is that the overhead is in wait queue setup and tear down
> in get_request_wait function. Throwing the following patch on top does improve
> things a bit, but we are still in the negative territory. I can't explain why.
> Everything suppose to be faster. So I'm staring at the execution profile at
> the moment.
>
Hmm, that's a bit disappointing. Like you said though, I'm sure we
should be able to get better performance out of this.
I'll look at it and see if we can rework it.
--
SUSE Labs, Novell Inc.
next prev parent reply other threads:[~2005-04-12 14:21 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-05 2:16 Processes stuck on D state on Dual Opteron Claudio Martins
2005-04-05 2:12 ` Andrew Morton
2005-04-10 2:28 ` Claudio Martins
2005-04-10 2:47 ` Andrew Morton
2005-04-10 3:19 ` Claudio Martins
2005-04-11 0:38 ` Claudio Martins
2005-04-11 6:36 ` Nick Piggin
2005-04-11 9:55 ` Nick Piggin
2005-04-11 12:45 ` Nick Piggin
2005-04-11 14:05 ` Claudio Martins
2005-04-11 22:59 ` Nick Piggin
2005-04-12 0:22 ` Claudio Martins
2005-04-12 0:46 ` Andrew Morton
2005-04-13 0:31 ` Claudio Martins
2005-04-13 2:24 ` Nick Piggin
2005-04-12 1:19 ` Nick Piggin
2005-04-12 7:07 ` Jens Axboe
2005-04-12 8:03 ` Chen, Kenneth W
2005-04-12 11:09 ` Nick Piggin [this message]
2005-04-12 11:26 ` Nick Piggin
2005-04-12 12:04 ` Nick Piggin
2005-04-12 17:07 ` Thomas Davis
2005-04-12 18:33 ` Chen, Kenneth W
2005-04-13 1:45 ` Nick Piggin
2005-04-11 23:46 ` Neil Brown
2005-04-12 0:30 ` Claudio Martins
2005-04-10 2:53 ` Nick Piggin
2005-04-10 3:22 ` Claudio Martins
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=425BAC55.7020506@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=ctpm@rnl.ist.utl.pt \
--cc=kenneth.w.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/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.