Date: Thu, 19 Aug 2010 13:32:15 +0400 From: pluknet <pluknet@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Kostik Belousov <kostikbel@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580 Message-ID: <AANLkTinsqLqx0=d=BQWitLyvrPs=hT0aMVahfVEfXAqW@mail.gmail.com> In-Reply-To: <699547258.794609.1282176294566.JavaMail.root@erie.cs.uoguelph.ca> References: <AANLkTimXxF0US60NsbOV_HvRrib7SJWmrLqpEpznPTxB@mail.gmail.com> <699547258.794609.1282176294566.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 August 2010 04:04, Rick Macklem <rmacklem@uoguelph.ca> wrote: >> On 18 August 2010 12:07, pluknet <pluknet@gmail.com> wrote: >> > On 17 August 2010 20:04, Kostik Belousov <kostikbel@gmail.com> wrote: >> > >> >> >> >> Also please take a note of the John' suggestion to use the taskqueue. >> > >> > I decided to go this road. Thank you both. >> > Now I do nfs buildkernel survive and prepare some benchmark results. >> > >> > I'm away from home, so I can only do email and haven't looked at the > patch, but I think you might want to consider avoiding the malloc() > failure by calling malloc(... M_WAITOK); before grabbing the mutex. > Then, set the pointer to NULL if you use it and free it at the end > (I tend to test for non-NULL before calling free(), but others have > pointed out that this isn't necessary.) > > I believe this is called "Dykstra's technique", although I used it > a lot before I found out it had been published. > > I think handling the case where malloc() fails correctly could > be difficult which is why I suggested the above. > > Good luck with the patch, rick Nice :) I need to step back and get a timeout to re-think how to use this technique. -- wbr, pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinsqLqx0=d=BQWitLyvrPs=hT0aMVahfVEfXAqW>