On Mon, Jun 16, 2014 at 04:29:15PM +0200, Michal Hocko wrote:
> > They're all in the mainline now.
>
> git grep CFTYPE_ON_ON_DFL origin/master didn't show me anything.
lol, it should have been CFTYPE_ONLY_ON_DFL.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe
On Mon 16-06-14 10:12:33, Tejun Heo wrote:
> On Mon, Jun 16, 2014 at 04:04:48PM +0200, Michal Hocko wrote:
> > > For whatever reason, a user is stuck with thread-level granularity for
> > > controllers which work that way, the user can use the old hierarchies
> > > for them for the time being.
> >
On Mon, Jun 16, 2014 at 04:04:48PM +0200, Michal Hocko wrote:
> > For whatever reason, a user is stuck with thread-level granularity for
> > controllers which work that way, the user can use the old hierarchies
> > for them for the time being.
>
> So he can mount memcg with new cgroup API and
On Mon 16-06-14 09:57:41, Tejun Heo wrote:
> Hello, Michal.
>
> On Mon, Jun 16, 2014 at 02:59:15PM +0200, Michal Hocko wrote:
> > > There sure is a question of how fast userland will move to the new
> > > interface.
> >
> > Yeah, I was mostly thinking about those who would need to to bigger
> >
Hello, Michal.
On Mon, Jun 16, 2014 at 02:59:15PM +0200, Michal Hocko wrote:
> > There sure is a question of how fast userland will move to the new
> > interface.
>
> Yeah, I was mostly thinking about those who would need to to bigger
> changes. AFAIR threads will no longer be distributable
On Thu 12-06-14 12:51:05, Johannes Weiner wrote:
> On Thu, Jun 12, 2014 at 04:22:37PM +0200, Michal Hocko wrote:
> > On Thu 12-06-14 09:56:00, Johannes Weiner wrote:
> > > On Thu, Jun 12, 2014 at 03:22:07PM +0200, Michal Hocko wrote:
> > [...]
> > > > Anyway, the situation now is pretty chaotic. I
On Thu 12-06-14 12:17:33, Tejun Heo wrote:
> Hello, Michal.
>
> On Thu, Jun 12, 2014 at 04:22:37PM +0200, Michal Hocko wrote:
> > The primary question would be, whether this is is the best transition
> > strategy. I do not know how many users apart from developers are really
> > using unified
On Thu 12-06-14 12:17:33, Tejun Heo wrote:
Hello, Michal.
On Thu, Jun 12, 2014 at 04:22:37PM +0200, Michal Hocko wrote:
The primary question would be, whether this is is the best transition
strategy. I do not know how many users apart from developers are really
using unified hierarchy. I
On Thu 12-06-14 12:51:05, Johannes Weiner wrote:
On Thu, Jun 12, 2014 at 04:22:37PM +0200, Michal Hocko wrote:
On Thu 12-06-14 09:56:00, Johannes Weiner wrote:
On Thu, Jun 12, 2014 at 03:22:07PM +0200, Michal Hocko wrote:
[...]
Anyway, the situation now is pretty chaotic. I plan to
Hello, Michal.
On Mon, Jun 16, 2014 at 02:59:15PM +0200, Michal Hocko wrote:
There sure is a question of how fast userland will move to the new
interface.
Yeah, I was mostly thinking about those who would need to to bigger
changes. AFAIR threads will no longer be distributable between
On Mon 16-06-14 09:57:41, Tejun Heo wrote:
Hello, Michal.
On Mon, Jun 16, 2014 at 02:59:15PM +0200, Michal Hocko wrote:
There sure is a question of how fast userland will move to the new
interface.
Yeah, I was mostly thinking about those who would need to to bigger
changes. AFAIR
On Mon, Jun 16, 2014 at 04:04:48PM +0200, Michal Hocko wrote:
For whatever reason, a user is stuck with thread-level granularity for
controllers which work that way, the user can use the old hierarchies
for them for the time being.
So he can mount memcg with new cgroup API and others with
On Mon 16-06-14 10:12:33, Tejun Heo wrote:
On Mon, Jun 16, 2014 at 04:04:48PM +0200, Michal Hocko wrote:
For whatever reason, a user is stuck with thread-level granularity for
controllers which work that way, the user can use the old hierarchies
for them for the time being.
So he
On Mon, Jun 16, 2014 at 04:29:15PM +0200, Michal Hocko wrote:
They're all in the mainline now.
git grep CFTYPE_ON_ON_DFL origin/master didn't show me anything.
lol, it should have been CFTYPE_ONLY_ON_DFL.
--
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Thu, Jun 12, 2014 at 04:22:37PM +0200, Michal Hocko wrote:
> On Thu 12-06-14 09:56:00, Johannes Weiner wrote:
> > On Thu, Jun 12, 2014 at 03:22:07PM +0200, Michal Hocko wrote:
> [...]
> > > Anyway, the situation now is pretty chaotic. I plan to gather all the
> > > patchse posted so far and
Hello, Michal.
On Thu, Jun 12, 2014 at 04:22:37PM +0200, Michal Hocko wrote:
> The primary question would be, whether this is is the best transition
> strategy. I do not know how many users apart from developers are really
> using unified hierarchy. I would be worried that we merge a feature
On Thu 12-06-14 09:56:00, Johannes Weiner wrote:
> On Thu, Jun 12, 2014 at 03:22:07PM +0200, Michal Hocko wrote:
[...]
> > Anyway, the situation now is pretty chaotic. I plan to gather all the
> > patchse posted so far and repost for the future discussion. I just need
> > to finish some internal
On Thu, Jun 12, 2014 at 03:22:07PM +0200, Michal Hocko wrote:
> On Wed 11-06-14 11:36:31, Johannes Weiner wrote:
> [...]
> > This code is truly dreadful.
> >
> > Don't call it guarantee when it doesn't guarantee anything. I thought
> > we agreed that min, low, high, max, is reasonable
On Wed 11-06-14 11:36:31, Johannes Weiner wrote:
[...]
> This code is truly dreadful.
>
> Don't call it guarantee when it doesn't guarantee anything. I thought
> we agreed that min, low, high, max, is reasonable nomenclature, please
> use it consistently.
I can certainly change the internal
On Wed 11-06-14 11:36:31, Johannes Weiner wrote:
[...]
This code is truly dreadful.
Don't call it guarantee when it doesn't guarantee anything. I thought
we agreed that min, low, high, max, is reasonable nomenclature, please
use it consistently.
I can certainly change the internal naming.
On Thu, Jun 12, 2014 at 03:22:07PM +0200, Michal Hocko wrote:
On Wed 11-06-14 11:36:31, Johannes Weiner wrote:
[...]
This code is truly dreadful.
Don't call it guarantee when it doesn't guarantee anything. I thought
we agreed that min, low, high, max, is reasonable nomenclature, please
On Thu 12-06-14 09:56:00, Johannes Weiner wrote:
On Thu, Jun 12, 2014 at 03:22:07PM +0200, Michal Hocko wrote:
[...]
Anyway, the situation now is pretty chaotic. I plan to gather all the
patchse posted so far and repost for the future discussion. I just need
to finish some internal tasks
Hello, Michal.
On Thu, Jun 12, 2014 at 04:22:37PM +0200, Michal Hocko wrote:
The primary question would be, whether this is is the best transition
strategy. I do not know how many users apart from developers are really
using unified hierarchy. I would be worried that we merge a feature which
On Thu, Jun 12, 2014 at 04:22:37PM +0200, Michal Hocko wrote:
On Thu 12-06-14 09:56:00, Johannes Weiner wrote:
On Thu, Jun 12, 2014 at 03:22:07PM +0200, Michal Hocko wrote:
[...]
Anyway, the situation now is pretty chaotic. I plan to gather all the
patchse posted so far and repost for
On Wed, Jun 11, 2014 at 10:00:24AM +0200, 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
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 usecases which can benefit from hard
guarantees. There
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 usecases which can benefit from hard
guarantees. There
On Wed, Jun 11, 2014 at 10:00:24AM +0200, 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
28 matches
Mail list logo
