From: Mike Anderson <mike.anderson@us.ibm.com>
To: Richard Gooch <rgooch@ras.ucalgary.ca>
Cc: Jeremy Higdon <jeremy@classic.engr.sgi.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [RFT] Support for ~2144 SCSI discs
Date: Tue, 31 Jul 2001 12:59:26 -0700 [thread overview]
Message-ID: <20010731125926.B10914@us.ibm.com> (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>
In-Reply-To: <200107311225.f6VCPj003249@mobilix.ras.ucalgary.ca>; from rgooch@ras.ucalgary.ca on Tue, Jul 31, 2001 at 08:25:45AM -0400
Richard Gooch [rgooch@ras.ucalgary.ca] wrote:
> Jeremy Higdon writes:
> > With the sard patch and a 64 bit system, you start having
> > trouble at around 103 configured disks, because of the following
>
> So even without my patch, sard doesn't support the previous limit of
> 128 devices.
>
> > line in sd_init() (sd.c), because kmalloc doesn't like allocating
> > large chunks of memory:
> >
> > sd = kmalloc((sd_template.dev_max << 4) *
> > sizeof(struct hd_struct),
> > GFP_ATOMIC);
> >
> > Without sard, you'd have problems past 512 disks.
>
> Yes, when I was coding up the patch I noticed the use of GFP_ATOMIC in
> the allocation calls. I have two questions:
> - can we use GFP_KERNEL instead (why use GFP_ATOMIC)
> - can we switch to vmalloc() instead of kmalloc()?
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.
> Regards,
>
> Richard....
> Permanent: rgooch@atnf.csiro.au
> Current: rgooch@ras.ucalgary.ca
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
-Mike
--
Michael Anderson
mike.anderson@us.ibm.com
next prev parent reply other threads:[~2001-07-31 20:00 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 [this message]
2001-07-29 20:34 ` Alan Cox
2001-08-01 0:48 ` Richard Gooch
2001-08-01 1:05 ` Douglas Gilbert
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=20010731125926.B10914@us.ibm.com \
--to=mike.anderson@us.ibm.com \
--cc=jeremy@classic.engr.sgi.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox