Hello, Oleg.
Sorry about the delay.
On Mon, Feb 25, 2019 at 04:57:25PM +0100, Oleg Nesterov wrote:
> > As long as the task is
> > guaranteed to be trapped by signal stop afterwards (and they are), we
> > likely can use them the same way. The only thing to be careful about
> > would be ensuring
On 02/22, Tejun Heo wrote:
>
> > So I think it too should somehow interact with freezable_schedule/etc.
>
> You mean freezer_do_not_count(), right?
yes,
> As long as the task is
> guaranteed to be trapped by signal stop afterwards (and they are), we
> likely can use them the same way. The only
Hey, Oleg.
On Fri, Feb 22, 2019 at 05:34:42PM +0100, Oleg Nesterov wrote:
> > ptrace support is a lot less important than kill for sure but if at
> > all possible I think it'd be better to have it
>
> Tejun, I agree it would be better. I did not argue with that.
>
> The question is how this can
On 02/21, Roman Gushchin wrote:
>
> > > Generally speaking, any process hanging in D-state
> > > for a long time isn't the nicest object from the userspace's point of
> > > view.
> >
> > Roman, this is unfair comparison ;)
>
> Why not?
OK, you are trolling me, let me troll you back...
So,
Hi,
On 02/21, Tejun Heo wrote:
>
> So, I really wanna avoid allowing userspace to cause D state sleeps.
...
> ptrace support is a lot less important than kill for sure but if at
> all possible I think it'd be better to have it
Tejun, I agree it would be better. I did not argue with that.
The
On Thu, Feb 21, 2019 at 05:29:24PM +0100, Oleg Nesterov wrote:
> On 02/20, Roman Gushchin wrote:
> >
> > On Wed, Feb 20, 2019 at 03:37:48PM +0100, Oleg Nesterov wrote:
> > >
> > > I tried to not argue with intent, but to be honest I am more and more
> > > sceptical... Lets forget about ptrace for
Hello, Oleg.
On Thu, Feb 21, 2019 at 05:29:24PM +0100, Oleg Nesterov wrote:
> But to me this is a reasonable trade-off because this way we do not add
> additional complexity to the kernel.
So, I really wanna avoid allowing userspace to cause D state sleeps.
It's not impossible to work around but
On 02/20, Roman Gushchin wrote:
>
> On Wed, Feb 20, 2019 at 03:37:48PM +0100, Oleg Nesterov wrote:
> >
> > I tried to not argue with intent, but to be honest I am more and more
> > sceptical... Lets forget about ptrace for the moment.
> >
> > Once again, why do we want a killable freezer?
> >
> >
On Wed, Feb 20, 2019 at 03:37:48PM +0100, Oleg Nesterov wrote:
> On 02/19, Roman Gushchin wrote:
> >
> > It provides similar functionality as v1 freezer, but the interface
> > conforms to the cgroup v2 interface design principles, and it
> > provides a better user experience: tasks can be killed,
On 02/19, Roman Gushchin wrote:
>
> It provides similar functionality as v1 freezer, but the interface
> conforms to the cgroup v2 interface design principles, and it
> provides a better user experience: tasks can be killed, ptrace works,
I tried to not argue with intent, but to be honest I am
This patchset implements freezer for cgroup v2.
It provides similar functionality as v1 freezer, but the interface
conforms to the cgroup v2 interface design principles, and it
provides a better user experience: tasks can be killed, ptrace works,
there is no separate controller, which has to be
11 matches
Mail list logo
