linux-kernel - Re: [Patch] mm tracepoints update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Apr 2009 16:48:25 -0400
From:	Larry Woodman <lwoodman@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Fr馘駻ic Weisbecker 
	<fweisbec@...il.com>, Li Zefan <lizf@...fujitsu.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	eduard.munteanu@...ux360.ro, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, riel@...hat.com, rostedt@...dmis.org
Subject: Re: [Patch] mm tracepoints update - use case.

On Thu, 2009-04-23 at 07:47 -0400, Larry Woodman wrote:
> On Thu, 2009-04-23 at 10:42 +0200, Ingo Molnar wrote:

> > 
> > A balanced number of MM tracepoints, showing the concepts and the 
> > inner dynamics of the MM would be useful. We dont need every little 
> > detail traced (we have the function tracer for that), but a few key 
> > aspects would be nice to capture ...
> 
> I hear you, there is  lot of data coming out of these mm tracepoints as
> well as must of the other tracepoints I've played around with, we have
> to filter them.  I added them in locations that would allow us to debug
> a variety of real running systems such as a Wall St. trading server
> during the heaviest period of the day without rebooting a debug kernel.
> We can collect whatever is needed to figure out whats happening then
> turning it all off when we've collected enough.  We've seen systems
> experiencing performance problems caused by the "inner'ds" of the page
> reclaim code, memory leak problems cause by applications, excessive COW
> faults caused by applications that mmap() gigs of files then fork and
> applications that rely the kernel to flush out every modified page of
> those gigs of mmap()'d file data every 30 seconds via kupdate because
> other kernel do. The list goes on and on...  These tracepoints are in
> the same locations that we've placed debug code in debug kernels in the
> past.
> 
> Larry
> 
 
> > 
> > pagefaults, allocations, cache-misses, cache flushes and how pages 
> > shift between various queues in the MM would be a good start IMHO.
> > 
> > Anyway, i suspect your answer means a NAK :-( Would be nice if you 
> > would suggest a path out of that NAK.
> > 
> > 	Ingo
> 


I've overhauled the patch so that all page level tracing has been
removed unless it directly causes page reclamation.  At this point trace
individual pagefaults, unmaps and pageouts.  However, for all page
reclaim paths and writeback paths we now traces quantities of pages
activated, deactivated, written, reclaimed, etc,.  Also we now only
trace individual page allocations that cause further page reclamation to
occur.  This still provides the necessary microscopic level of detail
without tracing the movement of all the pageframes:


> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

View attachment "mm-tracepoints.patch" of type "text/x-patch" (17760 bytes)