All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Richard Gooch <rgooch@ras.ucalgary.ca>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [RFT] Support for ~2144 SCSI discs
Date: Tue, 31 Jul 2001 21:05:43 -0400	[thread overview]
Message-ID: <3B6755E7.B63FA6D5@torque.net> (raw)
In-Reply-To: <200107310030.f6V0UeJ13558@mobilix.ras.ucalgary.ca> <rgooch@ras.ucalgary.ca> <10107310041.ZM233282@classic.engr.sgi.com> <200107311225.f6VCPj003249@mobilix.ras.ucalgary.ca> <20010731125926.B10914@us.ibm.com> <200108010048.f710miA05150@mobilix.ras.ucalgary.ca>

Richard Gooch wrote:
> 
> Mike Anderson writes:
> > In previous experiments trying to connect up to 512 devices we
> > switched to vmalloc because the static nature of sd.c's allocation
> > exceeds 128k which I assumed was the max for kmalloc YMMV.
> 
> Yes, I figure on switching to vmalloc() and putting in an
> in_interrupt() test in sd_init() to make sure the vmalloc() is safe.
> 
> Eric: do you happen to know why there are these GFP_ATOMIC flags?
> To my knowledge, nothing calls sd_init() outside of process context.

Richard,
I've seen GFP_KERNEL take 10 minutes in lk 2.4.6 . The 
mm gets tweaked pretty often so it is difficult to know 
exactly how it will react when memory is tight. A time 
bound would be useful on GFP_KERNEL.

<opinion> It is best to find out quickly there is 
not enough memory and have some alternate strategy 
to cope with that problem. GFP_KERNEL in its current 
form should be taken out and shot. </opinion>

Doug Gilbert

  reply	other threads:[~2001-08-01  1:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-31  0:30 [RFT] Support for ~2144 SCSI discs Richard Gooch
2001-07-31  7:41 ` Jeremy Higdon
2001-07-31 12:25   ` Richard Gooch
2001-07-31 19:59     ` Mike Anderson
2001-07-29 20:34       ` Alan Cox
2001-08-01  0:48       ` Richard Gooch
2001-08-01  1:05         ` Douglas Gilbert [this message]
2001-08-02  5:13           ` Richard Gooch
2001-07-31 14:10 ` Eric Youngdale
2001-07-31 22:38   ` Mike Panetta
2001-08-01  0:39     ` Richard Gooch
2001-08-01 14:33     ` Eric Youngdale
2001-08-02 14:06 ` Karcaw
2001-08-02 15:03   ` Richard Gooch
     [not found] <no.id>
2001-08-02 15:08 ` Alan Cox
2001-08-02 15:13   ` Richard Gooch
2001-08-02 15:31 ` Alan Cox
2001-08-02 23:17   ` 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=3B6755E7.B63FA6D5@torque.net \
    --to=dougg@torque.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=rgooch@ras.ucalgary.ca \
    /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.