Kirill Tkhai writes:
> On 01.06.2018 18:25, Eric W. Biederman wrote:
>> Michal Hocko writes:
>>
>>> On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
Michal Hocko writes:
>>> [...]
> Group leader exiting early without tearing down the whole thread
> group should be quite rare as
Kirill Tkhai writes:
> On 01.06.2018 18:25, Eric W. Biederman wrote:
>> Michal Hocko writes:
>>
>>> On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
Michal Hocko writes:
>>> [...]
> Group leader exiting early without tearing down the whole thread
> group should be quite rare as
On 01.06.2018 18:25, Eric W. Biederman wrote:
> Michal Hocko writes:
>
>> On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
>>> Michal Hocko writes:
>> [...]
Group leader exiting early without tearing down the whole thread
group should be quite rare as well. No question that somebody
On 01.06.2018 18:25, Eric W. Biederman wrote:
> Michal Hocko writes:
>
>> On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
>>> Michal Hocko writes:
>> [...]
Group leader exiting early without tearing down the whole thread
group should be quite rare as well. No question that somebody
On Mon 04-06-18 09:31:46, Eric W. Biederman wrote:
[...]
> My key point is that it is easy to trigger which makes the current
> mm_update_next_owner a fundamentally flawed design, and something that
> needs to be fixed.
Ohh, absolutely agreed! I was not trying to argue that part of course.
--
On Mon 04-06-18 09:31:46, Eric W. Biederman wrote:
[...]
> My key point is that it is easy to trigger which makes the current
> mm_update_next_owner a fundamentally flawed design, and something that
> needs to be fixed.
Ohh, absolutely agreed! I was not trying to argue that part of course.
--
Michal Hocko writes:
> On Fri 01-06-18 10:25:59, Eric W. Biederman wrote:
>> Michal Hocko writes:
>>
>> > On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
>> >> Michal Hocko writes:
>> > [...]
>> >> > Group leader exiting early without tearing down the whole thread
>> >> > group should be
Michal Hocko writes:
> On Fri 01-06-18 10:25:59, Eric W. Biederman wrote:
>> Michal Hocko writes:
>>
>> > On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
>> >> Michal Hocko writes:
>> > [...]
>> >> > Group leader exiting early without tearing down the whole thread
>> >> > group should be
On Fri 01-06-18 10:25:59, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
> >> Michal Hocko writes:
> > [...]
> >> > Group leader exiting early without tearing down the whole thread
> >> > group should be quite rare as well. No question
On Fri 01-06-18 10:25:59, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
> >> Michal Hocko writes:
> > [...]
> >> > Group leader exiting early without tearing down the whole thread
> >> > group should be quite rare as well. No question
Michal Hocko writes:
> On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
>> Michal Hocko writes:
> [...]
>> > Group leader exiting early without tearing down the whole thread
>> > group should be quite rare as well. No question that somebody might do
>> > that on purpose though...
>>
>> The
Michal Hocko writes:
> On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
>> Michal Hocko writes:
> [...]
>> > Group leader exiting early without tearing down the whole thread
>> > group should be quite rare as well. No question that somebody might do
>> > that on purpose though...
>>
>> The
On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
> Michal Hocko writes:
[...]
> > Group leader exiting early without tearing down the whole thread
> > group should be quite rare as well. No question that somebody might do
> > that on purpose though...
>
> The group leader exiting early is a
On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
> Michal Hocko writes:
[...]
> > Group leader exiting early without tearing down the whole thread
> > group should be quite rare as well. No question that somebody might do
> > that on purpose though...
>
> The group leader exiting early is a
Michal Hocko writes:
> On Thu 31-05-18 20:07:28, Eric W. Biederman wrote:
>> Michal Hocko writes:
>>
>> > On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
>> >> This function searches for a new mm owner in children and siblings,
>> >> and then iterates over all processes in the system in unlikely
Michal Hocko writes:
> On Thu 31-05-18 20:07:28, Eric W. Biederman wrote:
>> Michal Hocko writes:
>>
>> > On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
>> >> This function searches for a new mm owner in children and siblings,
>> >> and then iterates over all processes in the system in unlikely
On Thu 31-05-18 20:07:28, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
> >> This function searches for a new mm owner in children and siblings,
> >> and then iterates over all processes in the system in unlikely case.
> >> Despite the case
On Thu 31-05-18 20:07:28, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
> >> This function searches for a new mm owner in children and siblings,
> >> and then iterates over all processes in the system in unlikely case.
> >> Despite the case
Michal Hocko writes:
> On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
>> This function searches for a new mm owner in children and siblings,
>> and then iterates over all processes in the system in unlikely case.
>> Despite the case is unlikely, its probability growths with the number
>> of
Michal Hocko writes:
> On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
>> This function searches for a new mm owner in children and siblings,
>> and then iterates over all processes in the system in unlikely case.
>> Despite the case is unlikely, its probability growths with the number
>> of
On 27.04.2018 21:05, Eric W. Biederman wrote:
> Michal Hocko writes:
>
>> On Thu 26-04-18 21:28:18, Michal Hocko wrote:
>>> On Thu 26-04-18 11:19:33, Eric W. Biederman wrote:
Michal Hocko writes:
> I've had a patch to remove owner few years
On 27.04.2018 21:05, Eric W. Biederman wrote:
> Michal Hocko writes:
>
>> On Thu 26-04-18 21:28:18, Michal Hocko wrote:
>>> On Thu 26-04-18 11:19:33, Eric W. Biederman wrote:
Michal Hocko writes:
> I've had a patch to remove owner few years back. It needed some work
> to
ebied...@xmission.com (Eric W. Biederman) writes:
> Kirill Tkhai do you think you would be able adapt Michal Hoko's old
> patch at https://marc.info/?l=linux-kernel=143635857131756=2
> that replaces mm->owner with mm->memcg?
Ouch. At least compared to the current kernel your patch is wide
of
ebied...@xmission.com (Eric W. Biederman) writes:
> Kirill Tkhai do you think you would be able adapt Michal Hoko's old
> patch at https://marc.info/?l=linux-kernel=143635857131756=2
> that replaces mm->owner with mm->memcg?
Ouch. At least compared to the current kernel your patch is wide
of
Michal Hocko writes:
> On Thu 26-04-18 21:28:18, Michal Hocko wrote:
>> On Thu 26-04-18 11:19:33, Eric W. Biederman wrote:
>> > Michal Hocko writes:
>> >
>> > > I've had a patch to remove owner few years back. It needed some work
>> > > to finish but maybe
Michal Hocko writes:
> On Thu 26-04-18 21:28:18, Michal Hocko wrote:
>> On Thu 26-04-18 11:19:33, Eric W. Biederman wrote:
>> > Michal Hocko writes:
>> >
>> > > I've had a patch to remove owner few years back. It needed some work
>> > > to finish but maybe that would be a better than try to
On Thu 26-04-18 21:28:18, Michal Hocko wrote:
> On Thu 26-04-18 11:19:33, Eric W. Biederman wrote:
> > Michal Hocko writes:
> >
> > > I've had a patch to remove owner few years back. It needed some work
> > > to finish but maybe that would be a better than try to make
> > >
On Thu 26-04-18 21:28:18, Michal Hocko wrote:
> On Thu 26-04-18 11:19:33, Eric W. Biederman wrote:
> > Michal Hocko writes:
> >
> > > I've had a patch to remove owner few years back. It needed some work
> > > to finish but maybe that would be a better than try to make
> > > non-scalable thing
On Thu 26-04-18 11:19:33, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > I've had a patch to remove owner few years back. It needed some work
> > to finish but maybe that would be a better than try to make
> > non-scalable thing suck less.
>
> I have a question. Would
On Thu 26-04-18 11:19:33, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > I've had a patch to remove owner few years back. It needed some work
> > to finish but maybe that would be a better than try to make
> > non-scalable thing suck less.
>
> I have a question. Would it be reasonable
Michal Hocko writes:
> I've had a patch to remove owner few years back. It needed some work
> to finish but maybe that would be a better than try to make
> non-scalable thing suck less.
I have a question. Would it be reasonable to just have a mm->memcg?
That would appear to
Michal Hocko writes:
> I've had a patch to remove owner few years back. It needed some work
> to finish but maybe that would be a better than try to make
> non-scalable thing suck less.
I have a question. Would it be reasonable to just have a mm->memcg?
That would appear to be the simplest
On 04/26, Kirill Tkhai wrote:
>
> We can rework this simply by adding a list of tasks to mm.
Perhaps, but then I think this list should not depend on mm->owner.
I mean, mm->list_of_group_leaders_which_use_this_mm can be used by coredump
and oom-killer at least. But this is not that simple...
On 04/26, Kirill Tkhai wrote:
>
> We can rework this simply by adding a list of tasks to mm.
Perhaps, but then I think this list should not depend on mm->owner.
I mean, mm->list_of_group_leaders_which_use_this_mm can be used by coredump
and oom-killer at least. But this is not that simple...
On 26.04.2018 16:07, Michal Hocko wrote:
> On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
>> This function searches for a new mm owner in children and siblings,
>> and then iterates over all processes in the system in unlikely case.
>> Despite the case is unlikely, its probability growths with the
On 26.04.2018 16:07, Michal Hocko wrote:
> On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
>> This function searches for a new mm owner in children and siblings,
>> and then iterates over all processes in the system in unlikely case.
>> Despite the case is unlikely, its probability growths with the
On 04/26, Michal Hocko wrote:
>
> then I suspect that we should be better off reconsidering
> mm->owner and try to come up with something more clever. I've had a
> patch to remove owner few years back.
Yeees, I do remember we discussed this but I forgot everything.
I agree, it would nice to turn
On 04/26, Michal Hocko wrote:
>
> then I suspect that we should be better off reconsidering
> mm->owner and try to come up with something more clever. I've had a
> patch to remove owner few years back.
Yeees, I do remember we discussed this but I forgot everything.
I agree, it would nice to turn
On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
> This function searches for a new mm owner in children and siblings,
> and then iterates over all processes in the system in unlikely case.
> Despite the case is unlikely, its probability growths with the number
> of processes in the system. The time,
On Thu 26-04-18 14:00:19, Kirill Tkhai wrote:
> This function searches for a new mm owner in children and siblings,
> and then iterates over all processes in the system in unlikely case.
> Despite the case is unlikely, its probability growths with the number
> of processes in the system. The time,
This function searches for a new mm owner in children and siblings,
and then iterates over all processes in the system in unlikely case.
Despite the case is unlikely, its probability growths with the number
of processes in the system. The time, spent on iterations, also growths.
I regulary observe
This function searches for a new mm owner in children and siblings,
and then iterates over all processes in the system in unlikely case.
Despite the case is unlikely, its probability growths with the number
of processes in the system. The time, spent on iterations, also growths.
I regulary observe
42 matches
Mail list logo