Douglas Gilbert writes:
> 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.
>
> 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>
Perhaps. But I don't think we should use GFP_ATOMIC just because
GFP_KERNEL might be slow! That's just sweeping the problem under the
carpet. If there are MM problems, then waiting 10 minutes for the SCSI
driver to load might provide encouragement for people to fix the
bloody thing.
In any case, using GFP_ATOMIC just means that it will fail, which is
probably worse than trying hard. Not being able to use my SCSI drive
is pretty disastrous on some of my machines. Also, sd_init() is
usually called very early on in the boot process. If memory is tight
at that point, we have more to worry about.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:16 EST