From: Arnd Bergmann <arnd@arndb.de>
To: Andrea Righi <andrea@betterlinux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>,
Mike Frysinger <vapier@gentoo.org>,
Matthew Wilcox <matthew@wil.cx>,
Al Viro <viro@zeniv.linux.org.uk>,
Joel Becker <jlbec@evilplan.org>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] fadvise: introduce POSIX_FADV_DONTNEED_FS
Date: Mon, 2 May 2011 13:57:10 +0200 [thread overview]
Message-ID: <201105021357.10560.arnd@arndb.de> (raw)
In-Reply-To: <1304093980-12877-1-git-send-email-andrea@betterlinux.com>
On Friday 29 April 2011, Andrea Righi wrote:
> NOTE #1: to avoid potential DoS in the system the rate of calls to
> fadvise(POSIX_FADV_DONTNEED_FS) from non-privileged users are limited
> according to these settings:
>
> - /proc/sys/vm/drop_pagecache_ratelimit: the minimum length of time
> allowed beetween two different bursts of fadvise(POSIX_FADV_DONTNEED_FS)
>
> - /proc/sys/vm/drop_pagecache_ratelimit_burst: the number of calls to
> fadvise(POSIX_FADV_DONTNEED_FS) that can be issued before enforcing
> the rate limiting
The ratelimiting interface does not give me the happy feeling I had with
the original extremely syscall and fadvise, or with strictly limiting it
to certain capabilities. The ratelimit bursts seem well suited for log
messages, but it's not like you would expect anyone to read the fadvise
man page describing these and think "oh, of course, that's obviously
why it has to be done this way".
I don't have a perfect solution myself, but there are a few things
that feel wrong about yours:
* The rules for /proc/sys/vm/drop_caches and the fadvise are different
* You need to tune two variables to set one thing
* The rate limit is independent of the number of file systems you
operate on: When you have mounted 20 file systems, you need to
sleep for five seconds after flushing half of them, but you can
flush one ten times in a row without being throttled.
* Returning an error gives no feedback about how soon it can
be retried, in case you really need to flush.
Arnd
prev parent reply other threads:[~2011-05-02 11:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 16:19 Andrea Righi
2011-05-02 11:57 ` Arnd Bergmann [this message]
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=201105021357.10560.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--cc=andrea@betterlinux.com \
--cc=david@fromorbit.com \
--cc=jlbec@evilplan.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=vapier@gentoo.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®