All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Anton Vorontsov <anton@enomsg.org>
Cc: Minchan Kim <minchan@kernel.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: Thu, 27 Jun 2013 22:24:29 -0700	[thread overview]
Message-ID: <20130627222429.d90ec469.akpm@linux-foundation.org> (raw)
In-Reply-To: <20130628043411.GA9100@teo>

On Thu, 27 Jun 2013 21:34:11 -0700 Anton Vorontsov <anton@enomsg.org> wrote:

> 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:
> > > 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.
> 
> OK, I am convinced that modes might be not necessary, but I see no big
> problem in current situation, we can add the strict mode and deprecate the
> "filtering" -- basically we'll implement the idea of requiring that
> userspace registers a separate fd for each level.
> 
> As one of the ways to change the interface, we can do the strict mode by
> writing levels in uppercase, and warn_once on lowercase levels, describing
> that the old behaviour will go away.

I do think the feature is too young to be bothered about
back-compatibility things.  We could put a little patch into 3.10
tomorrow which disables the vmpressure feature (just putting a few
"return 0"s in there would suffice), then turn the feature back on in
3.11-rc1.

Another option is to change the interface in 3.11 and say "sorry" if
that causes anyone trouble.  But that's obviously less desirable.


> Once (if ever) we remove the old
> behaviour, the apps trying the old-style lowercase levels will fail
> gracefully with EINVAL.
> 
> Or we can be honest and admit that we can't be perfect and just add an
> explicit versioning to the interface. :)
> 
> It might be unfortunate that we did not foresee this and have to change
> things that soon, but we did change interfaces in the past for a lot of
> sysfs and proc knobs, so it is not something new. Once the vmpressure
> feature will get even wider usage exposure, we might realize that we need
> to make even more changes...

Hopefully not ;) But the interface should be designed with that
possibility in mind, of course.


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

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Anton Vorontsov <anton@enomsg.org>
Cc: Minchan Kim <minchan@kernel.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: Thu, 27 Jun 2013 22:24:29 -0700	[thread overview]
Message-ID: <20130627222429.d90ec469.akpm@linux-foundation.org> (raw)
In-Reply-To: <20130628043411.GA9100@teo>

On Thu, 27 Jun 2013 21:34:11 -0700 Anton Vorontsov <anton@enomsg.org> wrote:

> 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:
> > > 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.
> 
> OK, I am convinced that modes might be not necessary, but I see no big
> problem in current situation, we can add the strict mode and deprecate the
> "filtering" -- basically we'll implement the idea of requiring that
> userspace registers a separate fd for each level.
> 
> As one of the ways to change the interface, we can do the strict mode by
> writing levels in uppercase, and warn_once on lowercase levels, describing
> that the old behaviour will go away.

I do think the feature is too young to be bothered about
back-compatibility things.  We could put a little patch into 3.10
tomorrow which disables the vmpressure feature (just putting a few
"return 0"s in there would suffice), then turn the feature back on in
3.11-rc1.

Another option is to change the interface in 3.11 and say "sorry" if
that causes anyone trouble.  But that's obviously less desirable.


> Once (if ever) we remove the old
> behaviour, the apps trying the old-style lowercase levels will fail
> gracefully with EINVAL.
> 
> Or we can be honest and admit that we can't be perfect and just add an
> explicit versioning to the interface. :)
> 
> It might be unfortunate that we did not foresee this and have to change
> things that soon, but we did change interfaces in the past for a lot of
> sysfs and proc knobs, so it is not something new. Once the vmpressure
> feature will get even wider usage exposure, we might realize that we need
> to make even more changes...

Hopefully not ;) But the interface should be designed with that
possibility in mind, of course.



  parent reply	other threads:[~2013-06-28  5:24 UTC|newest]

Thread overview: 68+ 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  3:17 ` Luiz Capitulino
2013-06-27  9:26 ` Michal Hocko
2013-06-27  9:26   ` Michal Hocko
2013-06-27 13:34   ` Luiz Capitulino
2013-06-27 13:34     ` Luiz Capitulino
2013-06-27 14:59     ` Michal Hocko
2013-06-27 14:59       ` Michal Hocko
2013-06-27 15:53   ` Minchan Kim
2013-06-27 15:53     ` Minchan Kim
2013-06-27 17:42     ` Michal Hocko
2013-06-27 17:42       ` Michal Hocko
2013-06-27 15:44 ` Minchan Kim
2013-06-27 15:44   ` Minchan Kim
2013-06-27 22:02 ` Andrew Morton
2013-06-27 22:02   ` Andrew Morton
2013-06-28  0:02   ` Minchan Kim
2013-06-28  0:02     ` Minchan Kim
2013-06-28  0:34     ` Andrew Morton
2013-06-28  0:34       ` Andrew Morton
2013-06-28  0:58       ` Anton Vorontsov
2013-06-28  0:58         ` Anton Vorontsov
2013-06-28  1:13         ` Andrew Morton
2013-06-28  1:13           ` Andrew Morton
2013-06-28  4:34           ` Anton Vorontsov
2013-06-28  4:34             ` Anton Vorontsov
2013-06-28  5:07             ` Anton Vorontsov
2013-06-28  5:07               ` Anton Vorontsov
2013-06-28 14:00               ` Luiz Capitulino
2013-06-28 14:00                 ` Luiz Capitulino
2013-06-28 16:57                 ` Anton Vorontsov
2013-06-28 16:57                   ` Anton Vorontsov
2013-06-28 17:09                   ` Anton Vorontsov
2013-06-28 17:09                     ` Anton Vorontsov
2013-06-28 18:25                     ` Luiz Capitulino
2013-06-28 18:25                       ` Luiz Capitulino
2013-06-28 18:45                       ` Anton Vorontsov
2013-06-28 18:45                         ` Anton Vorontsov
2013-06-28 18:58                         ` Luiz Capitulino
2013-06-28 18:58                           ` Luiz Capitulino
2013-06-28 18:45                     ` Luiz Capitulino
2013-06-28 18:45                       ` Luiz Capitulino
2013-06-28 18:55                       ` Anton Vorontsov
2013-06-28 18:55                         ` Anton Vorontsov
2013-06-28 19:44                         ` Luiz Capitulino
2013-06-28 19:44                           ` Luiz Capitulino
2013-06-29  0:56                           ` Anton Vorontsov
2013-06-29  0:56                             ` Anton Vorontsov
2013-07-01  8:22                             ` Hyunhee Kim
2013-07-01  8:22                               ` Hyunhee Kim
2013-07-02  4:32                               ` Anton Vorontsov
2013-07-02  4:32                                 ` Anton Vorontsov
2013-07-02  8:29                                 ` Hyunhee Kim
2013-07-02  8:29                                   ` Hyunhee Kim
2013-07-02 13:29                             ` Michal Hocko
2013-07-02 13:29                               ` Michal Hocko
2013-07-02 14:59                             ` Luiz Capitulino
2013-07-02 14:59                               ` Luiz Capitulino
2013-07-02 17:24                               ` Anton Vorontsov
2013-07-02 17:24                                 ` Anton Vorontsov
2013-07-02 18:38                                 ` Luiz Capitulino
2013-07-02 18:38                                   ` Luiz Capitulino
2013-06-28  5:24             ` Andrew Morton [this message]
2013-06-28  5:24               ` Andrew Morton
2013-06-28 13:43             ` Luiz Capitulino
2013-06-28 13:43               ` Luiz Capitulino
2013-06-28  9:04           ` Minchan Kim
2013-06-28  9:04             ` Minchan Kim

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=20130627222429.d90ec469.akpm@linux-foundation.org \
    --to=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 \
    --cc=minchan@kernel.org \
    /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.