All of lore.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 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.