[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CE055A4.5010403@aljex.com>
Date: Sun, 14 Nov 2010 16:33:24 -0500
From: "Brian K. White" <brian@...ex.com>
To: rsync@...ts.samba.org
CC: linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: fadvise DONTNEED implementation (or lack thereof)
On 11/14/2010 12:20 AM, Ben Gamari wrote:
> On Sun, 14 Nov 2010 14:09:29 +0900 (JST), KOSAKI Motohiro<kosaki.motohiro@...fujitsu.com> wrote:
>> Because we have an alternative solution already. please try memcgroup :)
>>
> Alright, fair enough. It still seems like there are many cases where
> fadvise seems more appropriate, but memcg should at least satisfy my
> personal needs so I'll shut up now. Thanks!
>
> - Ben
Could someone expand on this a little?
The "there are no users of this feature" argument is indeed a silly one.
I've only wanted the ability to perform i/o without poisoning the cache
since oh, 10 or more years ago at least. It really hurts my users since
they are all direct login interactive db app users. No load balancing
web interface can hide the fact when a box goes to a crawl.
How would one use memcgroup to prevent a backup or other large file
operation from wiping out the cache with used-once garbage?
(note for rsync in particular, how does this help rsync on other platforms?)
--
bkw
--
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