All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Pierre Tardy <tardyp@gmail.com>, Ingo Molnar <mingo@elte.hu>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Tom Zanussi <tzanussi@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	linux-kernel@vger.kernel.org, arjan@infradead.org,
	ziga.mahkovec@gmail.com, davem <davem@davemloft.net>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [RFC] Tracer Ring Buffer splice() vs page cache [was: Re: Perf and ftrace [was Re: PyTimechart]]
Date: Tue, 18 May 2010 11:16:26 -0400	[thread overview]
Message-ID: <20100518151626.GA7748@Krystal> (raw)
In-Reply-To: <1274185160.5605.7787.camel@twins>

* Peter Zijlstra (peterz@infradead.org) wrote:
> On Mon, 2010-05-17 at 18:42 -0400, Mathieu Desnoyers wrote:
> > I'll continue to look into this. One of the things I noticed that that we could
> > possibly use the "steal()" operation to steal the pages back from the page cache
> > to repopulate the ring buffer rather than continuously allocating new pages. If
> > steal() fails for some reasons, then we can fall back on page allocation. I'm
> > not sure it is safe to assume anything about pages being in the page cache
> > though. 
> 
> 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.

> 
> > Maybe the safest route is to just allocate new pages for now.
> 
> Yes, that seems to be the only sane approach.

Yes, a good start anyway.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Pierre Tardy <tardyp@gmail.com>, Ingo Molnar <mingo@elte.hu>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Tom Zanussi <tzanussi@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	linux-kernel@vger.kernel.org, arjan@infradead.org,
	ziga.mahkovec@gmail.com, davem <davem@davemloft.net>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [RFC] Tracer Ring Buffer splice() vs page cache [was: Re: Perf and ftrace [was Re: PyTimechart]]
Date: Tue, 18 May 2010 11:16:26 -0400	[thread overview]
Message-ID: <20100518151626.GA7748@Krystal> (raw)
In-Reply-To: <1274185160.5605.7787.camel@twins>

* Peter Zijlstra (peterz@infradead.org) wrote:
> On Mon, 2010-05-17 at 18:42 -0400, Mathieu Desnoyers wrote:
> > I'll continue to look into this. One of the things I noticed that that we could
> > possibly use the "steal()" operation to steal the pages back from the page cache
> > to repopulate the ring buffer rather than continuously allocating new pages. If
> > steal() fails for some reasons, then we can fall back on page allocation. I'm
> > not sure it is safe to assume anything about pages being in the page cache
> > though. 
> 
> 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.

> 
> > Maybe the safest route is to just allocate new pages for now.
> 
> Yes, that seems to be the only sane approach.

Yes, a good start anyway.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

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

  reply	other threads:[~2010-05-18 15:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-14 18:32 [RFC] Tracer Ring Buffer splice() vs page cache [was: Re: Perf and ftrace [was Re: PyTimechart]] Mathieu Desnoyers
2010-05-14 18:32 ` Mathieu Desnoyers
2010-05-14 18:49 ` Peter Zijlstra
2010-05-14 18:49   ` Peter Zijlstra
2010-05-17 22:42   ` Mathieu Desnoyers
2010-05-17 22:42     ` Mathieu Desnoyers
2010-05-18 12:19     ` Peter Zijlstra
2010-05-18 12:19       ` Peter Zijlstra
2010-05-18 15:16       ` Mathieu Desnoyers [this message]
2010-05-18 15:16         ` Mathieu Desnoyers
2010-05-18 15:23         ` Peter Zijlstra
2010-05-18 15:23           ` Peter Zijlstra
2010-05-18 15:43           ` Mathieu Desnoyers
2010-05-18 15:43             ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100518151626.GA7748@Krystal \
    --to=mathieu.desnoyers@efficios.com \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=cl@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=fweisbec@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tardyp@gmail.com \
    --cc=tj@kernel.org \
    --cc=tzanussi@gmail.com \
    --cc=ziga.mahkovec@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.