linux-kernel - Re: [RFC] Tracer Ring Buffer splice() vs page cache [was: Re: Perf and ftrace [was Re: PyTimechart]]

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] [day] [month] [year] [list]

Message-ID: <20100518154327.GC7748@Krystal>
Date:	Tue, 18 May 2010 11:43:27 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Pierre Tardy <tardyp@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Tom Zanussi <tzanussi@...il.com>,
	Paul Mackerras <paulus@...ba.org>,
	linux-kernel@...r.kernel.org, arjan@...radead.org,
	ziga.mahkovec@...il.com, davem <davem@...emloft.net>,
	linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [RFC] Tracer Ring Buffer splice() vs page cache [was: Re: Perf
	and ftrace [was Re: PyTimechart]]

* Peter Zijlstra (peterz@...radead.org) wrote:
> On Tue, 2010-05-18 at 11:16 -0400, Mathieu Desnoyers wrote:
> > > Also, suppose it was still in the page-cache and still dirty, a steal()
> > > would then punch a hole in the file.
> > 
> > page_cache_pipe_buf_steal starts by doing a wait_on_page_writeback(page); and
> > then does a try_to_release_page(page, GFP_KERNEL). Only if that succeeds is the
> > action of stealing succeeding. 
> 
> If you're going to wait for writeback I don't really see the advantage
> of stealing over simply allocating a new page.

That would allow the ring buffer to use a bounded amount of memory and not
pollute the page cache uselessly. When allocating pages as you propose, the
tracer will quickly fill and pollute the page cache with trace file pages, which
will have a large impact on I/O behavior. But in 99.9999% of use-cases, we don't
ever need to access them after they have been saved to disk.

By re-stealing its own pages after waiting for the writeback to complete, the
ring buffer would use a bounded amount of pages. If larger buffers are needed,
the user just has to specify a larger buffer size.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/