Hello, Li.
On Thu, Aug 08, 2013 at 10:53:16AM +0800, Li Zefan wrote:
> I would like to see this happen. I have a feeling that we're deprecating
> features a bit aggressively without providing alternatives.
I'd rework it prolly next week but this has to go one way or another.
There's no way we're
Hello, Li.
On Thu, Aug 08, 2013 at 10:53:16AM +0800, Li Zefan wrote:
I would like to see this happen. I have a feeling that we're deprecating
features a bit aggressively without providing alternatives.
I'd rework it prolly next week but this has to go one way or another.
There's no way we're
>> If somebody needs a notification interface (and there is no one available
>> right now) then you cannot prevent from such a pointless work anyway...
>
> I'm gonna add one for freezer state transitions. It'll be simple
> "this file changed" thing and will probably apply that to at least oom
>
Hello, Michal.
On Wed, Aug 07, 2013 at 03:26:13PM +0200, Michal Hocko wrote:
> I would rather see it not changed unless it really is a big win in the
> cgroup core. So far I do not see anything like that (just look at
> __cgroup_from_dentry which needs to be exported to allow for the move).
The
On Wed 07-08-13 08:43:21, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Aug 07, 2013 at 02:18:36PM +0200, Michal Hocko wrote:
> > How is it specific to memcg? The fact only memcg uses the interface
> > doesn't imply it is memcg specific.
>
> I don't follow. It's only for memcg. That is *by
Hello, Michal.
On Wed, Aug 07, 2013 at 02:18:36PM +0200, Michal Hocko wrote:
> How is it specific to memcg? The fact only memcg uses the interface
> doesn't imply it is memcg specific.
I don't follow. It's only for memcg. That is *by definition* memcg
specific. It's the verbatim meaning of
On Tue 06-08-13 12:15:09, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Aug 06, 2013 at 05:58:04PM +0200, Michal Hocko wrote:
> > I am objecting to moving the generic part of that code into memcg. The
> > memcg part and the additional complexity (all the parsing and conditions
> > for signalling)
On Tue 06-08-13 12:15:09, Tejun Heo wrote:
Hello, Michal.
On Tue, Aug 06, 2013 at 05:58:04PM +0200, Michal Hocko wrote:
I am objecting to moving the generic part of that code into memcg. The
memcg part and the additional complexity (all the parsing and conditions
for signalling) is
Hello, Michal.
On Wed, Aug 07, 2013 at 02:18:36PM +0200, Michal Hocko wrote:
How is it specific to memcg? The fact only memcg uses the interface
doesn't imply it is memcg specific.
I don't follow. It's only for memcg. That is *by definition* memcg
specific. It's the verbatim meaning of the
On Wed 07-08-13 08:43:21, Tejun Heo wrote:
Hello, Michal.
On Wed, Aug 07, 2013 at 02:18:36PM +0200, Michal Hocko wrote:
How is it specific to memcg? The fact only memcg uses the interface
doesn't imply it is memcg specific.
I don't follow. It's only for memcg. That is *by definition*
Hello, Michal.
On Wed, Aug 07, 2013 at 03:26:13PM +0200, Michal Hocko wrote:
I would rather see it not changed unless it really is a big win in the
cgroup core. So far I do not see anything like that (just look at
__cgroup_from_dentry which needs to be exported to allow for the move).
The end
If somebody needs a notification interface (and there is no one available
right now) then you cannot prevent from such a pointless work anyway...
I'm gonna add one for freezer state transitions. It'll be simple
this file changed thing and will probably apply that to at least oom
and
Hello, Michal.
On Tue, Aug 06, 2013 at 05:58:04PM +0200, Michal Hocko wrote:
> I am objecting to moving the generic part of that code into memcg. The
> memcg part and the additional complexity (all the parsing and conditions
> for signalling) is already in the memcg code.
But how is it generic
On Mon 05-08-13 15:44:31, Tejun Heo wrote:
> Hey, Michal.
>
> On Mon, Aug 05, 2013 at 09:16:41PM +0200, Michal Hocko wrote:
[...]
> > Besides that, is fsnotify really an interface to be used under memory
> > pressure? I might be wrong but from a quick look fsnotify depends on
> > GFP_KERNEL
On Mon 05-08-13 15:44:31, Tejun Heo wrote:
Hey, Michal.
On Mon, Aug 05, 2013 at 09:16:41PM +0200, Michal Hocko wrote:
[...]
Besides that, is fsnotify really an interface to be used under memory
pressure? I might be wrong but from a quick look fsnotify depends on
GFP_KERNEL allocation
Hello, Michal.
On Tue, Aug 06, 2013 at 05:58:04PM +0200, Michal Hocko wrote:
I am objecting to moving the generic part of that code into memcg. The
memcg part and the additional complexity (all the parsing and conditions
for signalling) is already in the memcg code.
But how is it generic if
Hey, Michal.
On Mon, Aug 05, 2013 at 09:16:41PM +0200, Michal Hocko wrote:
> I keep hearing that over and over. And I also keep hearing that there
> are users who do not like many simplifications because they are breaking
> their usecases. Users are those who matter to me. Hey some of them are
>
On Mon 05-08-13 12:29:58, Tejun Heo wrote:
> Hello, Michal.
>
> On Mon, Aug 05, 2013 at 06:01:07PM +0200, Michal Hocko wrote:
> > Could you be more specific about what is so "overboard" about this
> > interface? I am not familiar with internals much, so I cannot judge the
> > complexity part, but
Hello, Michal.
On Mon, Aug 05, 2013 at 06:01:07PM +0200, Michal Hocko wrote:
> Could you be more specific about what is so "overboard" about this
> interface? I am not familiar with internals much, so I cannot judge the
> complexity part, but I thought that eventfd was intended for this kind
> of
On Sun 04-08-13 12:07:21, Tejun Heo wrote:
> Hello,
Hi Tejun,
> Like many other things in cgroup, cgroup_event is way too flexible and
> complex - it strives to provide completely flexible event monitoring
> facility in cgroup proper which allows any number of users to monitor
> custom events.
On Sun 04-08-13 12:07:21, Tejun Heo wrote:
Hello,
Hi Tejun,
Like many other things in cgroup, cgroup_event is way too flexible and
complex - it strives to provide completely flexible event monitoring
facility in cgroup proper which allows any number of users to monitor
custom events. This
Hello, Michal.
On Mon, Aug 05, 2013 at 06:01:07PM +0200, Michal Hocko wrote:
Could you be more specific about what is so overboard about this
interface? I am not familiar with internals much, so I cannot judge the
complexity part, but I thought that eventfd was intended for this kind
of
On Mon 05-08-13 12:29:58, Tejun Heo wrote:
Hello, Michal.
On Mon, Aug 05, 2013 at 06:01:07PM +0200, Michal Hocko wrote:
Could you be more specific about what is so overboard about this
interface? I am not familiar with internals much, so I cannot judge the
complexity part, but I thought
Hey, Michal.
On Mon, Aug 05, 2013 at 09:16:41PM +0200, Michal Hocko wrote:
I keep hearing that over and over. And I also keep hearing that there
are users who do not like many simplifications because they are breaking
their usecases. Users are those who matter to me. Hey some of them are
even
Hello,
Like many other things in cgroup, cgroup_event is way too flexible and
complex - it strives to provide completely flexible event monitoring
facility in cgroup proper which allows any number of users to monitor
custom events. This is overboard, to say the least, and I strongly
think that
Hello,
Like many other things in cgroup, cgroup_event is way too flexible and
complex - it strives to provide completely flexible event monitoring
facility in cgroup proper which allows any number of users to monitor
custom events. This is overboard, to say the least, and I strongly
think that
26 matches
Mail list logo
