From: Cong Wang <amwang@redhat.com>
To: John Stoffel <john@stoffel.org>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Cong Wang <xiyou.wangcong@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Matthew Wilcox <matthew@wil.cx>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
Keiichi Kii <k-keiichi@bx.jp.nec.com>
Subject: Re: [RFC Patch] fs: implement per-file drop caches
Date: Thu, 31 May 2012 14:28:16 +0800 [thread overview]
Message-ID: <1338445696.19369.27.camel@cr0> (raw)
In-Reply-To: <20422.14538.833061.105058@quad.stoffel.home>
On Wed, 2012-05-30 at 11:12 -0400, John Stoffel wrote:
> Cong> This is a draft patch of implementing per-file drop caches.
>
> Interesting. So can I do this from outside a process? I'm a
> SysAdmin, so my POV is from noticing, finding and fixing performance
> problems when the system is under pressure.
Yes, sure, we need to write a utility (or patch an existing one) to do
this for you admins.
>
> Cong> It introduces a new fcntl command F_DROP_CACHES to drop
> Cong> file caches of a specific file. The reason is that currently
> Cong> we only have a system-wide drop caches interface, it could
> Cong> cause system-wide performance down if we drop all page caches
> Cong> when we actually want to drop the caches of some huge file.
>
> How can I tell how much cache is used by a file? And what is the
> performance impact of this when run on a busy system? And what does
> this patch buy us since I figure the VM should already be dropping
> caches once the system comes under mem pressure...
>
AFAIK, we don't export such information to user-space, we only have
system-wide statistics.
Keiichi (in Cc) once wrote a patch to implement page cache tracepoint:
http://marc.info/?l=linux-mm&m=131102496904326&w=3
but the patches are still not in upstream.
Thanks!
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Cong Wang <amwang@redhat.com>
To: John Stoffel <john@stoffel.org>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Cong Wang <xiyou.wangcong@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Matthew Wilcox <matthew@wil.cx>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
Keiichi Kii <k-keiichi@bx.jp.nec.com>
Subject: Re: [RFC Patch] fs: implement per-file drop caches
Date: Thu, 31 May 2012 14:28:16 +0800 [thread overview]
Message-ID: <1338445696.19369.27.camel@cr0> (raw)
In-Reply-To: <20422.14538.833061.105058@quad.stoffel.home>
On Wed, 2012-05-30 at 11:12 -0400, John Stoffel wrote:
> Cong> This is a draft patch of implementing per-file drop caches.
>
> Interesting. So can I do this from outside a process? I'm a
> SysAdmin, so my POV is from noticing, finding and fixing performance
> problems when the system is under pressure.
Yes, sure, we need to write a utility (or patch an existing one) to do
this for you admins.
>
> Cong> It introduces a new fcntl command F_DROP_CACHES to drop
> Cong> file caches of a specific file. The reason is that currently
> Cong> we only have a system-wide drop caches interface, it could
> Cong> cause system-wide performance down if we drop all page caches
> Cong> when we actually want to drop the caches of some huge file.
>
> How can I tell how much cache is used by a file? And what is the
> performance impact of this when run on a busy system? And what does
> this patch buy us since I figure the VM should already be dropping
> caches once the system comes under mem pressure...
>
AFAIK, we don't export such information to user-space, we only have
system-wide statistics.
Keiichi (in Cc) once wrote a patch to implement page cache tracepoint:
http://marc.info/?l=linux-mm&m=131102496904326&w=3
but the patches are still not in upstream.
Thanks!
next prev parent reply other threads:[~2012-05-31 6:28 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-30 13:38 [RFC Patch] fs: implement per-file drop caches Cong Wang
2012-05-30 13:38 ` Cong Wang
2012-05-30 15:12 ` John Stoffel
2012-05-30 15:12 ` John Stoffel
2012-05-31 6:28 ` Cong Wang [this message]
2012-05-31 6:28 ` Cong Wang
2012-05-30 15:14 ` Pádraig Brady
2012-05-30 15:14 ` Pádraig Brady
2012-05-30 15:14 ` Pádraig Brady
2012-05-31 6:20 ` Cong Wang
2012-05-31 6:20 ` Cong Wang
2012-05-31 6:20 ` Cong Wang
2012-05-31 6:30 ` KOSAKI Motohiro
2012-05-31 6:30 ` KOSAKI Motohiro
2012-05-31 6:30 ` KOSAKI Motohiro
2012-05-31 12:11 ` Cong Wang
2012-05-31 12:11 ` Cong Wang
2012-05-31 12:11 ` Cong Wang
2012-05-31 19:09 ` KOSAKI Motohiro
2012-05-31 19:09 ` KOSAKI Motohiro
2012-05-31 19:09 ` KOSAKI Motohiro
2012-06-01 11:32 ` Cong Wang
2012-06-01 11:32 ` Cong Wang
2012-06-01 11:32 ` Cong Wang
2012-06-01 13:08 ` John Stoffel
2012-06-01 13:08 ` John Stoffel
2012-06-04 3:28 ` Cong Wang
2012-06-04 3:28 ` Cong Wang
2012-06-04 3:28 ` Cong Wang
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=1338445696.19369.27.camel@cr0 \
--to=amwang@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=john@stoffel.org \
--cc=k-keiichi@bx.jp.nec.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew@wil.cx \
--cc=viro@zeniv.linux.org.uk \
--cc=xiyou.wangcong@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.