public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Mark Peloquin <peloquin@us.ibm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Bio pool & scsi scatter gather pool usage
Date: Thu, 18 Apr 2002 09:17:17 -0700	[thread overview]
Message-ID: <3CBEF18D.F18BAA76@zip.com.au> (raw)
In-Reply-To: <OFCEC9D152.09A1A6B2-ON85256B9F.0047D732@pok.ibm.com>

Mark Peloquin wrote:
> 
> I'm experiencing a problem using the bio pool created in
> 2.5.7 and I'm not quite able to put my finger on the cause
> and hoped somone might have the knowledge and insight to
> understand this problem.
> 
> In EVMS, we are adding code to deal with BIO splitting, to
> enable our feature modules, such as DriveLinking, LVM, & MD
> Linear, etc to break large BIOs up on chunk size or lower
> level device boundaries.

Could I suggest that this code not be part of EVMS, but that
you implement it as a library within the core kernel?  Lots of
stuff is going to need BIO splitting - software RAID, ataraid,
XFS, etc.  May as well talk with Jens, Martin Petersen, Arjan,
Neil Brown.  Do it once, do it right...

> ...
> 
> The allocation and initialization of the resulting split
> BIOs seems to be correct and works in light loads. However,
> under heavier loads, the assert in scsi_merge.c:82
> {BUG_ON(!sgpnt)} fires, due to the fact that scatter gather
> pool for MAX_PHYS_SEGMENTS (128) is empty. This is occurring
> at interrupt time when __scsi_end_request is attempting to
> queue the next request.

You're not the only one...  That is placeholder code which
Jens plans to complete at a later time.
 
> Its not perfectly clear to me how switching from a private
> BIO pool to the 2.5 BIO pool should affect the usage of the
> scsi driver's scatter gather pools.
> 
> Rather than simply increasing the size of scatter gather
> pools I hope to understand how these changes resulted in
> this behaviour so the proper solution can be determined.
> 
> Another data point: I have observed that the BIO pool does
> get depleted below the 50% point of its mininum value, and
> in such cases mempool_alloc (the internal worker for
> bio_alloc) tries to free up more memory (I assume to grow
> the pool) by waking bdflush. As a result, even more
> pressure is put on the BIO pool when the dirty buffers
> are being flushed.

Makes sense.

> ...
> 
> Have I caused a problem by unrealistically increasing
> pressure on the BIO pool by a factor of 8? Or have I
> discovered a problem that can occur on very heavy loads?
> What are your thoughts on a recommended solution?

Hopefully, once scsi_merge is able to handle the allocation
failure correctly, we won't have a problem any more.

As a temp thing I guess you could increase the size of that
mempool.

-

  reply	other threads:[~2002-04-18 16:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-18 13:58 Bio pool & scsi scatter gather pool usage Mark Peloquin
2002-04-18 16:17 ` Andrew Morton [this message]
2002-04-18 17:35   ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2002-04-18 18:23 Mark Peloquin
2002-04-18 18:57 ` Andrew Morton
2002-04-19 15:44   ` Denis Vlasenko
2002-04-25 19:43 ` Mike Fedyk
2002-04-25 19:56   ` Andrew Morton
2002-04-25 19:59   ` David Mansfield
2002-04-18 22:58 Mark Peloquin
2002-04-18 23:36 ` Alan Cox
2002-04-18 23:48   ` Andrew Morton
2002-04-19  7:29     ` Stephen Lord
2002-04-19  8:08       ` Joe Thornber
2002-04-19  8:51         ` Alan Cox
2002-04-19  8:58       ` Alan Cox
2002-04-19 15:27         ` Steve Lord
2002-04-19 15:57           ` Alan Cox
2002-04-19 15:51             ` Rik van Riel
2002-04-22  6:50         ` Suparna Bhattacharya
2002-04-22  7:06           ` arjan
2002-04-22  7:54             ` Suparna Bhattacharya
2002-04-24 10:20         ` Helge Hafting
2002-04-19 18:15     ` Oliver Xymoron
2002-04-18 23:11 Douglas Gilbert

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=3CBEF18D.F18BAA76@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peloquin@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