On Fri, May 15, 2020 at 1:35 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
>
> On Fri 15-05-20 16:20:04, Li Zefan wrote:
> > On 2020/5/15 14:56, Michal Hocko wrote:
> > > On Thu 14-05-20 15:52:59, Roman Gushchin wrote:
> [...]
> > >>> I thought the user should ensure not do this, but now I think it makes sense to just bypass
> > >>> the interrupt case.
> > >>
> > >> I think now it's mostly a legacy of the opt-out kernel memory accounting.
> > >> Actually we can relax this requirement by forcibly overcommit the memory cgroup
> > >> if the allocation is happening from the irq context, and punish it afterwards.
> > >> Idk how much we wanna this, hopefully nobody is allocating large non-temporarily
> > >> objects from an irq.
> > >
> > > I do not think we want to pretend that remote charging from the IRQ
> > > context is supported. Why don't we simply WARN_ON(in_interrupt()) there?
> > >
> >
> > How about:
> >
> > static inline bool memcg_kmem_bypass(void)
> > {
> > if (in_interrupt()) {
> > WARN_ON(current->active_memcg);
> > return true;
> > }
>
> Why not simply
>
> if (WARN_ON_ONCE(in_interrupt())
> return true;
>
> the idea is that we want to catch any __GFP_ACCOUNT user from IRQ
> context because this just doesn't work and we do not plan to support it
> for now and foreseeable future. If this is reduced only to active_memcg
> then we are only getting a partial picture.
>
There are SLAB_ACCOUNT kmem caches which do allocations in IRQ context
(see sk_prot_alloc()), so, either we make charging work in IRQ or no
warnings at all.
