Re: [PATCH][RFC] splice support

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Thu, 30 Mar 2006 16:38:10 +0200
Jens Axboe <axboe@suse.de> wrote:

> On Thu, Mar 30 2006, KAMEZAWA Hiroyuki wrote:
> > On Thu, 30 Mar 2006 15:53:46 +0200
> > Jens Axboe <axboe@suse.de> wrote:
> > 
> > > > I don't know about sendfile() but this looks client can hold server's
> > > > memory, when server uses sendfile() 64k/conn.
> > > 
> > > You mean when the server uses splice, 64kb (well 16 pages actually) /
> > > connection? That's a correct observation, I wouldn't think that pinning
> > > that small a number of pages is likely to cause any issues. At least I
> > > can think of much worse pinning by just doing IO :-)
> > > 
> > My point is consumer can sleep forever and pages are pinnded forever.
> > And people who use splice() will not notice they are pinning pages.
> > 
> > But as you say, it's not problem in usual situation.
> > Maybe I'm too pessimistic how my cusomers play with Linux ;)
> 
> It's a valid concern, however as mentioned there's a number of ways in
> which a user can pin memory already. 
Yes.

>Perhaps this general problem should be capped elsewhere?
> 
I don't know. but this new one cannot be catched by overcommit_memory but
a user can consume not-reclaimable memory.

To be honest, I have to work with crash-dump. Sometimes cutomers request me to 
find out "how pages is used and why memory cannot be reclaimed ?" from dump.
So, I don't like unknown "1" reference to page-cache from some codes.
splice can increase this unkonwn 1 reference to some extent.

But I like idea of splice itself :).

-Kame

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/