On Wed, Jun 11, 2014 at 04:11:17PM +0200, Michal Hocko wrote:
> > I still think it'd be less useful than "high", but as there seem to be
> > use cases which can be served with that and especially as a part of a
> > consistent control scheme, I have no objection.
> >
> > "low" definitely requires a
On Wed 11-06-14 08:31:09, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Jun 11, 2014 at 09:57:29AM +0200, Michal Hocko wrote:
> > Is this the kind of symmetry Tejun is asking for and that would make
> > change is Nack position? I am still not sure it satisfies his soft
>
> Yes, pretty much. What
Hello, Michal.
On Wed, Jun 11, 2014 at 09:57:29AM +0200, Michal Hocko wrote:
> Is this the kind of symmetry Tejun is asking for and that would make
> change is Nack position? I am still not sure it satisfies his soft
Yes, pretty much. What primarily bothered me was the soft/hard
guarantees being
On Tue 10-06-14 12:57:56, Johannes Weiner wrote:
> On Mon, Jun 09, 2014 at 03:52:51PM -0700, Greg Thelen wrote:
> >
> > On Fri, Jun 06 2014, Michal Hocko wrote:
> >
> > > Some users (e.g. Google) would like to have stronger semantic than low
> > > limit offers currently. The fallback mode is not
On Tue, Jun 10 2014, Johannes Weiner wrote:
> On Mon, Jun 09, 2014 at 03:52:51PM -0700, Greg Thelen wrote:
>>
>> On Fri, Jun 06 2014, Michal Hocko wrote:
>>
>> > Some users (e.g. Google) would like to have stronger semantic than low
>> > limit offers currently. The fallback mode is not desira
On Mon, Jun 09, 2014 at 03:52:51PM -0700, Greg Thelen wrote:
>
> On Fri, Jun 06 2014, Michal Hocko wrote:
>
> > Some users (e.g. Google) would like to have stronger semantic than low
> > limit offers currently. The fallback mode is not desirable and they
> > prefer hitting OOM killer rather than
On Fri, Jun 06 2014, Michal Hocko wrote:
> Some users (e.g. Google) would like to have stronger semantic than low
> limit offers currently. The fallback mode is not desirable and they
> prefer hitting OOM killer rather than ignoring low limit for protected
> groups. There are other possible usec
Hello,
On Mon, Jun 09, 2014 at 10:30:42AM +0200, Michal Hocko wrote:
> On Fri 06-06-14 11:29:14, Tejun Heo wrote:
> > Why is this necessary?
>
> It allows user/admin to set the default behavior.
By recomipling the kernel for something which can be trivially
configured post-boot without any diffe
On Fri 06-06-14 11:29:14, Tejun Heo wrote:
> Hello, Michal.
>
> On Fri, Jun 06, 2014 at 04:46:50PM +0200, Michal Hocko wrote:
> > +choice
> > + prompt "Memory Resource Controller reclaim protection"
> > + depends on MEMCG
> > + help
>
> Why is this necessary?
It allows user/admin to set th
A bit of addition.
Let's *please* think through how memcg should be configured and
different knobs / limits interact with each other and come up with a
consistent scheme before adding more shits on top. This "oh I know
this use case and maybe that behavior is necessary too, let's add N
different
Hello, Michal.
On Fri, Jun 06, 2014 at 04:46:50PM +0200, Michal Hocko wrote:
> +choice
> + prompt "Memory Resource Controller reclaim protection"
> + depends on MEMCG
> + help
Why is this necessary?
- This doesn't affect boot.
- memcg requires runtime config *anyway*.
- The config
11 matches
Mail list logo
