All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Anton Vorontsov <anton@enomsg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan@kernel.org>,
	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 09:43:25 -0400	[thread overview]
Message-ID: <20130628094325.45f5139b@redhat.com> (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.

Agreed this is a good solution.

> 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. Once (if ever) we remove the old
> behaviour, the apps trying the old-style lowercase levels will fail
> gracefully with EINVAL.

Why don't we just break it? There's no non-development kernel released
with this interface yet.

--
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: Luiz Capitulino <lcapitulino@redhat.com>
To: Anton Vorontsov <anton@enomsg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan@kernel.org>,
	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 09:43:25 -0400	[thread overview]
Message-ID: <20130628094325.45f5139b@redhat.com> (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.

Agreed this is a good solution.

> 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. Once (if ever) we remove the old
> behaviour, the apps trying the old-style lowercase levels will fail
> gracefully with EINVAL.

Why don't we just break it? There's no non-development kernel released
with this interface yet.

  parent reply	other threads:[~2013-06-28 14:01 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
2013-06-28  5:24               ` Andrew Morton
2013-06-28 13:43             ` Luiz Capitulino [this message]
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=20130628094325.45f5139b@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=anton@enomsg.org \
    --cc=hyunhee.kim@samsung.com \
    --cc=kmpark@infradead.org \
    --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.