linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Anton Vorontsov <anton@enomsg.org>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org, mhocko@suse.cz,
	kmpark@infradead.org, hyunhee.kim@samsung.com
Subject: Re: [PATCH v2] vmpressure: implement strict mode
Date: Fri, 28 Jun 2013 18:04:50 +0900	[thread overview]
Message-ID: <20130628090450.GA9956@bbox> (raw)
In-Reply-To: <20130627181353.3d552e64.akpm@linux-foundation.org>

On Thu, Jun 27, 2013 at 06:13:53PM -0700, Andrew Morton wrote:
> On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov <anton@enomsg.org> wrote:
> 
> > On Thu, Jun 27, 2013 at 05:34:33PM -0700, Andrew Morton wrote:
> > > > If so, userland daemon would receive lots of events which are no interest.
> > > 
> > > "lots"?  If vmpressure is generating events at such a high frequency that
> > > this matters then it's already busted?
> > 
> > Current frequency is 1/(2MB). Suppose we ended up scanning the whole
> > memory on a 2GB host, this will give us 1024 hits. Doesn't feel too much*
> > to me... But for what it worth, I am against adding read() to the
> > interface -- just because we can avoid the unnecessary switch into the
> > kernel.
> 
> What was it they said about premature optimization?
> 
> I think I'd rather do nothing than add a mode hack (already!).
> 
> The information Luiz wants is already available with the existing
> interface, so why not just use it until there is a real demonstrated
> problem?
> 
> But all this does point at the fact that the chosen interface was not a
> good one.  And it's happening so soon :( A far better interface would
> be to do away with this level filtering stuff in the kernel altogether.
> Register for events and you get all the events, simple.  Or require that
> userspace register a separate time for each level, or whatever.
> 
> Something clean and simple which leaves the policy in userspace,
> please.  Not this.

Anton, Michal,

Tend to agree. I have been thought that current vmpressure heuristic
could be much fluctuated with various workloads so that how we could make
it stable with another parameters in future so everyone has satisfactory
result with just common general value of low/medium/critical but
different window size. It's not easy for kernel to handle it, IMO.
So as Andrew says, how about leaving the policy in userspace?

For example, we kernel just can expose linear index(ex, 0~100) using
some algorithm(ex, current vmpressure_win/reclaimed/scan) and userland
could poll it with his time granularity and handle the situation and
reset it.

It's a just simple example without enough considering.
Anyway the point is that isn't it worth to think over userspace policy
and what's indicator kernel could expose to user space?


> 
> (Why didn't vmpressure use netlink, btw?  Then we'd have decent payload
> delivery)
> 
> --
> 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>

-- 
Kind regards,
Minchan Kim

--
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>

      parent reply	other threads:[~2013-06-28  9:04 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27  3:17 [PATCH v2] vmpressure: implement strict mode Luiz Capitulino
2013-06-27  9:26 ` Michal Hocko
2013-06-27 13:34   ` Luiz Capitulino
2013-06-27 14:59     ` Michal Hocko
2013-06-27 15:53   ` Minchan Kim
2013-06-27 17:42     ` Michal Hocko
2013-06-27 15:44 ` Minchan Kim
2013-06-27 22:02 ` Andrew Morton
2013-06-28  0:02   ` Minchan Kim
2013-06-28  0:34     ` Andrew Morton
2013-06-28  0:58       ` Anton Vorontsov
2013-06-28  1:13         ` Andrew Morton
2013-06-28  4:34           ` Anton Vorontsov
2013-06-28  5:07             ` Anton Vorontsov
2013-06-28 14:00               ` Luiz Capitulino
2013-06-28 16:57                 ` Anton Vorontsov
2013-06-28 17:09                   ` Anton Vorontsov
2013-06-28 18:25                     ` Luiz Capitulino
2013-06-28 18:45                       ` Anton Vorontsov
2013-06-28 18:58                         ` Luiz Capitulino
2013-06-28 18:45                     ` Luiz Capitulino
2013-06-28 18:55                       ` Anton Vorontsov
2013-06-28 19:44                         ` Luiz Capitulino
2013-06-29  0:56                           ` Anton Vorontsov
2013-07-01  8:22                             ` Hyunhee Kim
2013-07-02  4:32                               ` Anton Vorontsov
2013-07-02  8:29                                 ` Hyunhee Kim
2013-07-02 13:29                             ` Michal Hocko
2013-07-02 14:59                             ` Luiz Capitulino
2013-07-02 17:24                               ` Anton Vorontsov
2013-07-02 18:38                                 ` Luiz Capitulino
2013-06-28  5:24             ` Andrew Morton
2013-06-28 13:43             ` Luiz Capitulino
2013-06-28  9:04           ` Minchan Kim [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=20130628090450.GA9956@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=anton@enomsg.org \
    --cc=hyunhee.kim@samsung.com \
    --cc=kmpark@infradead.org \
    --cc=lcapitulino@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    /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;
as well as URLs for NNTP newsgroup(s).