> -----Original Message----- > From: tao.peng@xxxxxxx [mailto:tao.peng@xxxxxxx] > Sent: Tuesday, September 20, 2011 10:44 PM > To: Myklebust, Trond > Cc: bhalevy@xxxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx; honey@xxxxxxxxxxxxxx; > rees@xxxxxxxxx > Subject: RE: [PATCH 2/3] pnfs: introduce pnfs private workqueue > > > > -----Original Message----- > > From: linux-nfs-owner@xxxxxxxxxxxxxxx > > [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] > > On Behalf Of Jim Rees > > Sent: Wednesday, September 21, 2011 8:29 AM > > To: Trond Myklebust > > Cc: Benny Halevy; linux-nfs@xxxxxxxxxxxxxxx; peter honeyman > > Subject: Re: [PATCH 2/3] pnfs: introduce pnfs private workqueue > > > > Trond Myklebust wrote: > > > > On Mon, 2011-09-19 at 23:18 -0400, Jim Rees wrote: > > > From: Peng Tao <bergwolf@xxxxxxxxx> > > > > > > For layoutdriver io done functions, default workqueue is not a good > place as > > > the code is executed in IO path. So add a pnfs private workqueue to > handle > > > them. > > > > > > Also change block and object layout code to make use of this private > > > workqueue. > > > > > > > Wait, what???? > > > > Why is the I/O path (i.e. the nfsiod queue) inappropriate for > > layoutdriver io_done functions? > The current code uses the system_wq to handle io_done functions. If any > function allocates memory in system_wq and causes dirty writeback in nfs > path, the io_done function can never be called because it is after the original > function in the system_wq. And you said that the rpciod/nfsiod is not the > ideal place because of memory allocation. So I suggested pnfs private > workqueue and Benny agreed on it. You appear to be optimizing for a corner case. Why? IOW: why do we need a whole new workqueue for something which is supposed to be extremely rare? Why can't we just use standard keventd or allocate a perfectly normal thread (e.g. the state recovery thread)? Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
