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 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.
--
Mi
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 qu
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 th
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 gr
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 com
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 is
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 proces
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 finish
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&m=143635857131756&w=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 that would be a better than try to mak
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 suc
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 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 solu
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...
Ole
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 n
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,
20 matches
Mail list logo
