public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Mike Anderson <mike.anderson@us.ibm.com>
Cc: Dipankar Sarma <dipankar@sequent.com>, linux-kernel@vger.kernel.org
Subject: Re: io_request_lock patch?
Date: Wed, 11 Jul 2001 21:20:22 +0200	[thread overview]
Message-ID: <20010711212022.H712@suse.de> (raw)
In-Reply-To: <20010710172545.A8185@in.ibm.com> <20010710160512.A25632@us.ibm.com> <20010711142311.B9220@in.ibm.com> <20010711090257.B27097@us.ibm.com>
In-Reply-To: <20010711090257.B27097@us.ibm.com>

On Wed, Jul 11 2001, Mike Anderson wrote:
> Dipankar Sarma [dipankar@sequent.com] wrote:
> > Hi Mike,
> > 
> > On Tue, Jul 10, 2001 at 04:05:12PM -0700, Mike Anderson wrote:
> > > The call to do_aic7xxx_isr appears that you are running the aic7xxx_old.c
> > > code. This driver is using the io_request_lock to protect internal data.
> > > The newer aic driver has its own lock. This is related to previous
> > > comments by Jens and Eric about lower level use of this lock.
> > 
> > There were some problems booting with the new aic7xxx driver and 2.4.4
> > kernel. This may have been fixed in later kernels, so we will check
> > this again. Besides, I wasn't aware that the new aic7xxx driver uses
> > a different locking model. Thanks for letting me know.
> > 
> > >  
> > >  I would like to know why the request_freelist is going empty? Having
> > >  __get_request_wait being called alot would appear to be not optimal.
> > 
> > It is not unreasonable for request IOCB pools to go empty, the important
> > issue is at what rate ? If a large portion of I/Os have to wait for
> > request structures to be freed, we may not be able to utilize the available
> > hardware bandwidth of the system optimally when we need, say, large
> > # of IOs/Sec. On the other hand, having large number of request structures
> > available may not necessarily give you large IOs/sec. The thing to look
> > at would be - how well are we utilizing the queueing capablility
> > of the hardware given a particular type of workload.
> 
> Jens, I think Dipankar might have stated my comment about questioning
> optimal utilization of a pool of resources shared by all device queues in
> the last sentence of the above paragraph. 
> 
> My thought was that if one has enough IO that cannot be merged on a queue
> you eat up request descriptors. If a request queue contains more requests
> than can be put in flight by the lower level to a spindle than this
> resource might be better used by other request queues.

True. In theory it would be possible to do request slot stealing from
idle queues, in fact it's doable without adding any additional overhead
to struct request. I did discuss this with [someone, forgot who] last
year, when the per-queue slots where introduced.

I'm not sure I want to do this though. If you have lots of disks, then
yes there will be some wastage if they are idle. IMO that's ok. What's
not ok and what I do want to fix is that slower devices get just as many
slots as a 15K disk for instance. For, say, floppy or CDROM devices we
really don't need to waste that much RAM. This will change for 2.5, not
before.

-- 
Jens Axboe


  reply	other threads:[~2001-07-11 19:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-10 11:55 io_request_lock patch? Dipankar Sarma
2001-07-10 23:05 ` Mike Anderson
2001-07-11  7:15   ` Jens Axboe
2001-07-11  8:53   ` Dipankar Sarma
2001-07-11  8:53     ` Jens Axboe
2001-07-11 14:02       ` Dipankar Sarma
2001-07-11 14:01         ` Jens Axboe
2001-07-11 14:55           ` Dipankar Sarma
2001-07-11 19:16             ` Jens Axboe
2001-07-11 16:02     ` Mike Anderson
2001-07-11 19:20       ` Jens Axboe [this message]
2001-07-11 20:13         ` Dipankar Sarma
2001-07-11 20:17           ` Jens Axboe
2001-07-11 21:05             ` Mike Anderson
2001-07-11  7:19 ` Jens Axboe
2001-07-11  8:39   ` Dipankar Sarma
2001-07-11  8:47     ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2001-07-09 19:39 Jonathan Lahr
2001-07-09 19:44 ` Jens Axboe
2001-07-10 19:49   ` Jonathan Lahr
2001-07-10 20:09     ` Eric Youngdale
2001-07-11  8:05       ` 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=20010711212022.H712@suse.de \
    --to=axboe@suse.de \
    --cc=dipankar@sequent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.anderson@us.ibm.com \
    /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