From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f199.google.com (mail-io0-f199.google.com [209.85.223.199]) by kanga.kvack.org (Postfix) with ESMTP id B5A216B0038 for ; Tue, 28 Nov 2017 18:02:02 -0500 (EST) Received: by mail-io0-f199.google.com with SMTP id x63so1207377ioe.18 for ; Tue, 28 Nov 2017 15:02:02 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id u35sor160007iou.218.2017.11.28.15.02.01 for (Google Transport Security); Tue, 28 Nov 2017 15:02:01 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1511841842-3786-1-git-send-email-zhouzhouyi@gmail.com> From: Zhouyi Zhou Date: Wed, 29 Nov 2017 07:02:01 +0800 Message-ID: Subject: Re: [PATCH 1/1] kasan: fix livelock in qlist_move_cache Content-Type: multipart/alternative; boundary="001a113f08a8bb69c8055f130195" Sender: owner-linux-mm@kvack.org List-ID: To: Dmitry Vyukov Cc: Andrey Ryabinin , Alexander Potapenko , kasan-dev , Linux-MM , "linux-kernel@vger.kernel.org" --001a113f08a8bb69c8055f130195 Content-Type: text/plain; charset="UTF-8" hi, I will prepare the environment to let the phenonmenon reappear today right after I reached my company. Cheers On Wednesday, November 29, 2017, Dmitry Vyukov wrote: > On Tue, Nov 28, 2017 at 6:56 PM, Dmitry Vyukov > wrote: > > On Tue, Nov 28, 2017 at 12:30 PM, Zhouyi Zhou > wrote: > >> Hi, > >> By using perf top, qlist_move_cache occupies 100% cpu did really > >> happen in my environment yesterday, or I > >> won't notice the kasan code. > >> Currently I have difficulty to let it reappear because the frontend > >> guy modified some user mode code. > >> I can repeat again and again now is > >> kgdb_breakpoint () at kernel/debug/debug_core.c:1073 > >> 1073 wmb(); /* Sync point after breakpoint */ > >> (gdb) p quarantine_batch_size > >> $1 = 3601946 > >> And by instrument code, maximum > >> global_quarantine[quarantine_tail].bytes reached is 6618208. > > > > On second thought, size does not matter too much because there can be > > large objects. Quarantine always quantize by objects, we can't part of > > an object into one batch, and another part of the object into another > > object. But it's not a problem, because overhead per objects is O(1). > > We can push a single 4MB object and overflow target size by 4MB and > > that will be fine. > > Either way, 6MB is not terribly much too. Should take milliseconds to > process. > > > > > > > > > >> I do think drain quarantine right in quarantine_put is a better > >> place to drain because cache_free is fine in > >> that context. I am willing do it if you think it is convenient :-) > > > Andrey, do you know of any problems with draining quarantine in push? > Do you have any objections? > > But it's still not completely clear to me what problem we are solving. > --001a113f08a8bb69c8055f130195 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable hi,
=C2=A0 =C2=A0 =C2=A0I will prepare the environment to let the pheno= nmenon reappear today right after I reached my company.
Cheers
On Wednesday, November 29, 2017, Dmitry Vyukov <dvyukov@google.com> wrote:
On Tue, Nov 28, 2017 at 6:56 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Nov 28, 2017 at 12:30 PM, Zhouyi Zhou <= zhouzhouyi@gmail.com> wrote:
>> Hi,
>>=C2=A0 =C2=A0 By using perf top, qlist_move_cache occupies 100% cpu= did really
>> happen in my environment yesterday, or I
>> won't notice the kasan code.
>>=C2=A0 =C2=A0 Currently I have difficulty to let it reappear becaus= e the frontend
>> guy modified some user mode code.
>>=C2=A0 =C2=A0 I can repeat again and again now is
>> kgdb_breakpoint () at kernel/debug/debug_core.c:1073
>> 1073 wmb(); /* Sync point after breakpoint */
>> (gdb) p quarantine_batch_size
>> $1 =3D 3601946
>>=C2=A0 =C2=A0 And by instrument code, maximum
>> global_quarantine[quarantine_tail].bytes reached is 6618208.<= br> >
> On second thought, size does not matter too much because there can be<= br> > large objects. Quarantine always quantize by objects, we can't par= t of
> an object into one batch, and another part of the object into another<= br> > object. But it's not a problem, because overhead per objects is O(= 1).
> We can push a single 4MB object and overflow target size by 4MB and > that will be fine.
> Either way, 6MB is not terribly much too. Should take milliseconds to = process.
>
>
>
>
>>=C2=A0 =C2=A0 I do think drain quarantine right in quarantine_put i= s a better
>> place to drain because cache_free is fine in
>> that context. I am willing do it if you think it is convenient :-)=


Andrey, do you know of any problems with draining quarantine in push?
Do you have any objections?

But it's still not completely clear to me what problem we are solving.<= br>
--001a113f08a8bb69c8055f130195-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org