From: "Jeff V. Merkey" <jmerkey@drdos.com>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: submit_bh leaves interrupts on upon return
Date: Thu, 03 Jun 2004 14:46:23 -0600 [thread overview]
Message-ID: <40BF8E1F.1060009@drdos.com> (raw)
In-Reply-To: <20040603085002.GG28915@suse.de>
Jens Axboe wrote:
>On Wed, Jun 02 2004, Jeff V. Merkey wrote:
>
>
>>Any reason why submit_bh should turn on interrupts after being called by
>>a process with ints off in 2.4.20? I see it's possible to sleep during
>>elevatoring, but why does it need to leave interrupts on if the calling
>>state was with ints off.
>>
>>
>
>It's illegal to call it with interrupts off, so... __make_request()
>doesn't save interrupt state, so you will always leave with interrupts
>enabled.
>
>
>
Jens
I noticed in the code it does not check for this when make_request is
called, so I altered the calling sequence to call with ints on. I don't
see much of a performance difference either way, so calling with ints on
was easy to instrument. I am posting about 80,000+ buffer heads per
second in with what I am doing, so filling out buffer_head structures
and submitting them ad hoc was causing some interrupt windows where the
chains were getting corrupted. I altered the calling sequence and added
atomic counters so I can submit and call with ints on to avoid the
corruption. One of the troublesome aspects of the manner in which
make_request is implemented in always needing a context of a thread for
sleeping to submit asynch I/O limits the ability to gang schedule large
disk I/O from the b_end_io callback. Would make performance a lot more
spectacular if it worked this way, but I am seeing good enough
performance with it left the way it is. 3Ware's 66Mhz ATA adapter in
this implementation is reaching almost 400 MB/S throughput on 2.4.20. I
have not tried this on 2.6 yet, but will later this month.
Also, I ported the kernel debugger from MANOS to Linux and made a lot of
significant enhancements and www.devicelogics.com is distributing it
from their website. If anyone wants a more pleasant debugger for the
kernel to work with, they are allowing downloads of the modules with a
patch. Not free (what is in this world) but very nice to work with.
Thanks for the response. Sorry I was out of touch for about a year. I
was going through a very nasty divorce with my wife of 24 years and I
discovered when something like that is happening in your life, you don't
have much attention for much else.
Jeff
next prev parent reply other threads:[~2004-06-03 16:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-03 2:58 submit_bh leaves interrupts on upon return Jeff V. Merkey
2004-06-03 8:50 ` Jens Axboe
2004-06-03 20:46 ` Jeff V. Merkey [this message]
2004-06-03 16:52 ` Jens Axboe
2004-06-03 20:59 ` Jeff V. Merkey
2004-06-03 17:03 ` Jens Axboe
2004-06-03 17:26 ` Linus Torvalds
2004-06-03 17:34 ` Jens Axboe
2004-06-03 23:56 ` Jeff V. Merkey
2004-06-03 21:17 ` Jeff V. Merkey
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=40BF8E1F.1060009@drdos.com \
--to=jmerkey@drdos.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox