> -----Original Message----- > From: Boaz Harrosh [mailto:bharrosh@xxxxxxxxxxx] > Sent: Monday, August 29, 2011 5:55 PM > To: David Miller > Cc: Myklebust, Trond; joe@xxxxxxxxxxx; bfields@xxxxxxxxxxxx; > neilb@xxxxxxx; linux-nfs@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 19/24] sunrpc: Remove unnecessary OOM logging > messages > > On 08/29/2011 02:37 PM, David Miller wrote: > > From: "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> > > Date: Mon, 29 Aug 2011 14:36:17 -0700 > > > >> Big NACK... > >> > >> By whose standard are those "not useful"? > > > > By mine, that's for sure. It's duplicating something that the > allocation > > layers are already going to print. > > I have a question about that. Are the dprints going to show the stack > backtrace? > Otherwise how can I see which exact allocation failed and was not > properly handled? > > If yes above? then I'm not sure I like it either, because am I'll be > getting a full > stack backtrace for every failed allocation? > > But I might like it if I try. How do I turn on allocation failures > prints? > Can I filter out to print only GFP_KERNEL failures and or other GFP > combinations? Right. If every GFP_ATOMIC or GFP_NOWAIT is going to print out stack traces, then we're heading for absolute insanity. If not, then the existing dprintk()s make a lot more sense, 'cos they are turned on only when the administrator notices a problem, and is trying to debug it. Trond ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
