On Mon, Sep 14, 2020 at 11:17 PM Michal Hocko wrote:
>
> On Mon 14-09-20 23:02:15, Chunxin Zang wrote:
> > On Mon, Sep 14, 2020 at 9:47 PM Michal Hocko wrote:
> >
> > > On Mon 14-09-20 21:25:59, Chunxin Zang wrote:
> > > > On Mon, Sep 14, 2020 at 5:30 PM Michal Hocko wrote:
> > > >
> > > > > The
On Mon 14-09-20 23:02:15, Chunxin Zang wrote:
> On Mon, Sep 14, 2020 at 9:47 PM Michal Hocko wrote:
>
> > On Mon 14-09-20 21:25:59, Chunxin Zang wrote:
> > > On Mon, Sep 14, 2020 at 5:30 PM Michal Hocko wrote:
> > >
> > > > The subject is misleading because this patch doesn't fix an infinite
> >
On Mon 14-09-20 21:25:59, Chunxin Zang wrote:
> On Mon, Sep 14, 2020 at 5:30 PM Michal Hocko wrote:
>
> > The subject is misleading because this patch doesn't fix an infinite
> > loop, right? It just allows the userspace to interrupt the operation.
> >
> >
> Yes, so we are making a separate patc
The subject is misleading because this patch doesn't fix an infinite
loop, right? It just allows the userspace to interrupt the operation.
On Wed 09-09-20 23:20:47, zangchun...@bytedance.com wrote:
> From: Chunxin Zang
>
> On our server, there are about 10k memcg in one machine. They use memory
On 9/9/20 11:52 PM, Matthew Wilcox wrote:
> On Wed, Sep 09, 2020 at 10:47:24PM +0100, Chris Down wrote:
>> Vlastimil Babka writes:
>> > - Exit also on other signals such as SIGABRT, SIGTERM? If I write to
>> > drop_caches
>> > and think it's too long, I would prefer to kill it by ctrl-c and not ju
Matthew Wilcox writes:
On Wed, Sep 09, 2020 at 10:47:24PM +0100, Chris Down wrote:
Vlastimil Babka writes:
> - Exit also on other signals such as SIGABRT, SIGTERM? If I write to
drop_caches
> and think it's too long, I would prefer to kill it by ctrl-c and not just kill
Oh dear, fatal_signal_p
On Wed, Sep 09, 2020 at 10:47:24PM +0100, Chris Down wrote:
> Vlastimil Babka writes:
> > - Exit also on other signals such as SIGABRT, SIGTERM? If I write to
> > drop_caches
> > and think it's too long, I would prefer to kill it by ctrl-c and not just
> > kill
>
> Oh dear, fatal_signal_pending(
On Wed, Sep 09, 2020 at 07:59:44PM +0200, Vlastimil Babka wrote:
> - Exit also on other signals such as SIGABRT, SIGTERM? If I write to
> drop_caches
> and think it's too long, I would prefer to kill it by ctrl-c and not just kill
> -9. Dunno if the canonical way of testing for this is if
> (signa
Vlastimil Babka writes:
- Exit also on other signals such as SIGABRT, SIGTERM? If I write to drop_caches
and think it's too long, I would prefer to kill it by ctrl-c and not just kill
Oh dear, fatal_signal_pending() doesn't consider cases with no more userspace
instructions due to SIG_DFL on T
On 9/9/20 5:20 PM, zangchun...@bytedance.com wrote:
> From: Chunxin Zang
>
> On our server, there are about 10k memcg in one machine. They use memory
> very frequently. When I tigger drop caches，the process will infinite loop
> in drop_slab_node.
>
> There are two reasons:
> 1.We have too many m
From: Chunxin Zang
On our server, there are about 10k memcg in one machine. They use memory
very frequently. When I tigger drop caches，the process will infinite loop
in drop_slab_node.
There are two reasons:
1.We have too many memcgs, even though one object freed in one memcg, the
sum of objec
Thanks! This looks reasonable to me, and avoids hard-to-reason-about changes in
the existing semantics.
zangchun...@bytedance.com writes:
Signed-off-by: Chunxin Zang
Signed-off-by: Muchun Song
Acked-by: Chris Down
12 matches
Mail list logo
