[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84144f020804291229t55d207afk97457f14175ebe18@mail.gmail.com>
Date: Tue, 29 Apr 2008 22:29:01 +0300
From: "Pekka Enberg" <penberg@...helsinki.fi>
To: "Christoph Lameter" <clameter@....com>
Cc: "Arjan van de Ven" <arjan@...radead.org>,
"Ingo Molnar" <mingo@...e.hu>, akpm@...ux-foundation.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Subject: Re: [2/2] vmallocinfo: Add caller information
On Tue, Apr 29, 2008 at 10:09 PM, Christoph Lameter <clameter@....com> wrote:
> > Well so we display out of whack backtraces? There are also issues on
> > platforms that do not have a stack in the classic sense (rotating register
> > file on IA64 and Sparc64 f.e.). Determining a backtrace can be very
> > expensive.
On Tue, Apr 29, 2008 at 10:23 PM, Pekka Enberg <penberg@...helsinki.fi> wrote:
> I think that's the key question here whether we need to enable this on
> production systems? If yes, why? If it's just a debugging aid, then I
> see Ingo's point of save_stack_trace(); otherwise the low-overhead
> __builtin_return_address() makes more sense.
Actually, this is vmalloc() so why do we even care? If there are
callers in the tree that use vmalloc() for performance sensitive
stuff, they ought to be converted to kmalloc() anyway, no?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists