Date: Mon, 10 Oct 2005 08:58:21 -0600 From: Scott Long <scottl@samsco.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: src-committers@FreeBSD.org, Peter Edwards <peadar@FreeBSD.org>, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, S?ren Schmidt <sos@FreeBSD.org> Subject: Re: cvs commit: src/sys/dev/ata atapi-cd.c Message-ID: <434A818D.3010100@samsco.org> In-Reply-To: <20051010101754.GC3975@garage.freebsd.pl> References: <20051010101013.GB3975@garage.freebsd.pl> <13707.1128939139@critter.freebsd.dk> <20051010101754.GC3975@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote: > On Mon, Oct 10, 2005 at 12:12:19PM +0200, Poul-Henning Kamp wrote: > +> In message <20051010101013.GB3975@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?434A818D.3010100>