cvs commit: src/sys/dev/ata atapi-cd.c

[Scott Long]

Pawel Jakub Dawidek wrote:
> On Mon, Oct 10, 2005 at 12:12:19PM +0200, Poul-Henning Kamp wrote:
> +> In message <20051010101013.GB3975 at garage.freebsd.pl>, Pawel Jakub Dawidek write
> +> s:
> +> >
> +> >On Mon, Oct 10, 2005 at 11:06:49AM +0200, S?ren Schmidt wrote:
> +> >+> On 09/10/2005, at 23:11, Peter Edwards wrote:
> +> >+> 
> +> >+> Why did you ask me to review this when you just committed it anyway ?
> +> >+> 
> +> >+> As I said I'm not sure this is the right way to fix this..
> +> >
> +> >It seems to be right. I do it in my GEOM classes to handle g_clone_bio()
> +> >failures better. So the only objection I may have is that it could be
> +> >done a bit cleaner:
> +> 
> +> Please see geom_disk.c
> 
> So bascially, you allocate next bio before sending current one?
> That's one way of doing it, but I prefer to treat bio allocation as atomic
> operation, ie. if I cannot allocate all bios, I send no bio down and call
> g_io_deliver(parent_bio, ENOMEM) right away.
> Do you see any protential problems with doing so?
> 

There are pros and cons, and Poul-Henning and I have been discussing 
something related to this recently.  The problem is that bio's get
allocated from UMA.  If there is a severe shortage of memory, you
might not be able to allocate enough bio's through the GEOM stack to do
I/O, but you need to do I/O in order to free up memory.  Trying to
allocate all bio's at the beginning of the transaction doesn't solve 
this, while recycling them one at a time can help significantly.  It's
still not a total solution, though.  Granted, this doesn't apply to the
case of a CD driver, but it's good to consider all of the cases and try
for a general solution.

Scott