From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id 8FC806B0005 for ; Tue, 31 May 2016 22:54:38 -0400 (EDT) Received: by mail-pf0-f197.google.com with SMTP id c84so4942975pfc.3 for ; Tue, 31 May 2016 19:54:38 -0700 (PDT) Received: from smtpbg302.qq.com (smtpbg302.qq.com. [184.105.206.27]) by mx.google.com with ESMTPS id c10si20354566pat.170.2016.05.31.19.54.37 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 31 May 2016 19:54:37 -0700 (PDT) Date: Wed, 1 Jun 2016 10:54:27 +0800 From: "shhuiw@foxmail.com" Subject: Re: Re: why use alloc_workqueue instead of create_singlethread_workqueue to create nvme_workq References: , <20160531145306.GB24107@localhost.localdomain> Mime-Version: 1.0 Message-ID: <2016060110542407705011@foxmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart033558812640_=----" Sender: owner-linux-mm@kvack.org List-ID: To: "keith.busch" Cc: "iamjoonsoo.kim" , linux-mm This is a multi-part message in MIME format. ------=_001_NextPart033558812640_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 VGhhbmtzLCBLZWl0aCENCg0KQW55IGlkZWEgb24gaG93IHRvIGZpeCB0aGUgd2FybmluZz8gSnVz dCBkcm9wIHRoZSBXUV9NRU1fUkVDTEFJTSBmb3IgbnZtZV93b3JrcSwgb3INCmxydSBkcmFpbiB3 b3JrIHNjaGVkdWxlIHNob3VsZCBiZSBjaGFuZ2VkPw0KDQoNCk9uIFR1ZSwgTWF5IDMxLCAyMDE2 IGF0IDA0OjQzOjM0UE0gKzA4MDAsIFdhbmcgU2hlbmctSHVpIHdyb3RlOg0KPiBSZWNlbnRseSBJ IG5vdGljZWQgd2FybmluZyBvbiBOVk1FIHByb2JlIGlmIENNQSBpcyBlbmFibGVkIG9uIG15IFNv QyBwbGF0Zm9ybQ0KPiAoWk9ORV9ETUEsIFpPTkVfRE1BMzIgYW5kIENNQSBlbmFibGVkIGluIHRo ZSBjb25maWcgZmlsZSk6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFdBUk5JTkc6IENQ VTogMCBQSUQ6IDYgYXQgbGludXgva2VybmVsL3dvcmtxdWV1ZS5jOjI0NDggY2hlY2tfZmx1c2hf ZGVwZW5kZW5jeSsweGI0LzB4MTBjDQo+IFsgICAgMC4xNTQwODNdIFs8ZmZmZmZjMDAwODBkNmRl MD5dIGNoZWNrX2ZsdXNoX2RlcGVuZGVuY3krMHhiNC8weDEwYw0KPiBbICAgIDAuMTU0MDg4XSBb PGZmZmZmYzAwMDgwZDhlODA+XSBmbHVzaF93b3JrKzB4NTQvMHgxNDANCj4gWyAgICAwLjE1NDA5 Ml0gWzxmZmZmZmMwMDA4MTY2YTBjPl0gbHJ1X2FkZF9kcmFpbl9hbGwrMHgxMzgvMHgxODgNCj4g WyAgICAwLjE1NDA5N10gWzxmZmZmZmMwMDA4MWFiMmRjPl0gbWlncmF0ZV9wcmVwKzB4Yy8weDE4 DQo+IFsgICAgMC4xNTQxMDFdIFs8ZmZmZmZjMDAwODE2MGU4OD5dIGFsbG9jX2NvbnRpZ19yYW5n ZSsweGY0LzB4MzUwDQo+IFsgICAgMC4xNTQxMDVdIFs8ZmZmZmZjMDAwODFiY2VmOD5dIGNtYV9h bGxvYysweGVjLzB4MWU0DQo+IFsgICAgMC4xNTQxMTBdIFs8ZmZmZmZjMDAwODQ0NmFkMD5dIGRt YV9hbGxvY19mcm9tX2NvbnRpZ3VvdXMrMHgzOC8weDQwDQo+IFsgICAgMC4xNTQxMTRdIFs8ZmZm ZmZjMDAwODBhMDkzYz5dIF9fZG1hX2FsbG9jKzB4NzQvMHgyNWMNCj4gWyAgICAwLjE1NDExOV0g WzxmZmZmZmMwMDA4NDgyOGQ4Pl0gbnZtZV9hbGxvY19xdWV1ZSsweGNjLzB4MzZjDQo+IFsgICAg MC4xNTQxMjNdIFs8ZmZmZmZjMDAwODQ4NGIyYz5dIG52bWVfcmVzZXRfd29yaysweDVjNC8weGRh OA0KPiBbICAgIDAuMTU0MTI4XSBbPGZmZmZmYzAwMDgwZDk1Mjg+XSBwcm9jZXNzX29uZV93b3Jr KzB4MTI4LzB4MmVjDQo+IFsgICAgMC4xNTQxMzJdIFs8ZmZmZmZjMDAwODBkOTc0ND5dIHdvcmtl cl90aHJlYWQrMHg1OC8weDQzNA0KPiBbICAgIDAuMTU0MTM2XSBbPGZmZmZmYzAwMDgwZGYwZWM+ XSBrdGhyZWFkKzB4ZDQvMHhlOA0KPiBbICAgIDAuMTU0MTQxXSBbPGZmZmZmYzAwMDgwOTNhYzA+ XSByZXRfZnJvbV9mb3JrKzB4MTAvMHg1MA0KIA0KVGhlIGxydSBkcmFpbiB3b3JrIGlzIHNjaGVk dWxlZCBvbiB0aGUgc3lzdGVtIHdvcmsgcXVldWUsIHdoaWNoIGlzIG5vdA0KdXNlZCBmb3IgbWVt b3J5IHJlY2xhaW0uIEJ1dCB0aGlzIHdvcmsgaXMgdXNlZCBmb3Igc3dhcCwgc28gbWF5YmUgaXQN CnNob3VsZCBiZSBzY2hlZHVsZWQgb24gYSBzdWNoIGEgd29yayBxdWV1ZSwgYW5kIHRoaXMgd2Fy bmluZyB3b3VsZCBnbw0KYXdheS4gVW5sZXNzIHRoZXJlJ3MgYSByZWFzb24gbm90IHRvIGhhdmUg YSBzeXN0ZW0gbWVtb3J5IHJlY2xhaW0gd29yaw0KcXVldWUsIEknbGwgbG9vayBpbnRvIHRoYXQu DQogDQo+IEJ1dCB0aGUgbG9nIG9ubHkgZXhwbGFpbmVkIHdoeSBjaGFuZ2VkIHRvIHdvcmtxdWV1 ZSBpbnN0ZWFkIG9mIHNjaGVkdWxlX3dvcmssIA0KPiBubyBjb21tZW50cyB3aHkgdXNlIGFsbG9j X3dvcmtxdWV1ZSBpbnN0ZWFkIG9mIGNyZWF0ZV9zaW5nbGV0aHJlYWRfd29ya3F1ZXVlLA0KPiB0 aG91Z2ggDQogDQpXZSByZW1vdmVkIHNpbmdsZSB0aHJlYWRlZCB3b3JrIHF1ZXVlcyBzbyBtdWx0 aXBsZSBjb250cm9sbGVycyBjYW4gYmUNCnByb2JlZCBpbiBwYXJhbGxlbC4NCiANCj4gICAgICAg ICJUaGUgb3JpZ2luYWwgY3JlYXRlXyp3b3JrcXVldWUoKSBmdW5jdGlvbnMgYXJlIGRlcHJlY2F0 ZWQgYW5kIHNjaGVkdWxlZCBmb3IgcmVtb3ZhbC4iIA0KPiAoRG9jdW1lbnRhdGlvbi93b3JrcXVl dWUudHh0OyBodHRwczovL3BhdGNod29yay5vemxhYnMub3JnL3BhdGNoLzU3NTU3MC8pLiANCj4g DQo+IFRoZSBrZXkgcG9pbnQgaXMgIl9fV1FfTEVHQUNZIiB3YXMgZHJvcHBlZC4gDQo+IElmIEkg Y2hhbmdlIHRvIHVzZSAibnZtZV93b3JrcSA9IGNyZWF0ZV9zaW5nbGV0aHJlYWRfd29ya3F1ZXVl KCJudm1lIik7IiwgIHRoZW4gbm8NCj4gd2FybmluZyBvbiBOVk1FIHByb2JlIGluIG15IGNhc2Uu DQo+IA0KPiBNeSBxdWVzdGlvbiBpcywgd2h5IHlvdSBkZWNpZGUgZHJvcCB0aGUgZmxhZyAiX19X UV9MRUdBQ1kiIGZvciBudm1lX3dvcmtxPw0KIA0KSSBkaWRuJ3QgZGVjaWRlIHRvIGRyb3AgdGhp cy4gVGhlIGZsYWcgaXMgdXNlZCBmb3IgZGVwcmVjYXRlZCB1c2FnZSwNCmJ1dCB0aGlzIGlzIG5l dyB1c2FnZS4NCiANCkkgdGhpbmsgdGhlIHJlYWwgaXNzdWUgaXMgbnZtZSB1c2VzIGEgV1FfTUVN X1JFQ0xBSU0gd29yayBxdWV1ZSBidXQgc3dhcA0KZG9lcyBub3QuIE9uZSBvZiB0aGVzZSBwcm9i YWJseSBuZWVkcyB0byBjaGFuZ2UuDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KTGludXgtbnZtZSBtYWlsaW5nIGxpc3QNCkxpbnV4LW52bWVAbGlz dHMuaW5mcmFkZWFkLm9yZw0KaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0 aW5mby9saW51eC1udm1lDQogDQoNCg0KUmVnYXJkcywNClNoZW5nLUh1aQ0KDQoNCg== ------=_001_NextPart033558812640_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Thanks, Keith!

Any= idea on how to fix the warning? Just drop the WQ_MEM_= RECLAIM for nvme_workq, or
lru drain work schedule should be changed?


On Tue, May 31, 2016 at 04:43:34PM +0800, Wang Sheng-Hui wrot= e:
=0A
> Recently I noticed warning on NVME probe if CMA is en= abled on my SoC platform
=0A
> (ZONE_DMA, ZONE_DMA32 and CMA e= nabled in the config file):
=0A
> ----------------------------= ----------------------------------------------------
=0A
> WAR= NING: CPU: 0 PID: 6 at linux/kernel/workqueue.c:2448 check_flush_dependenc= y+0xb4/0x10c
=0A
> [    0.154083] [<fffffc00= 080d6de0>] check_flush_dependency+0xb4/0x10c
=0A
> [ &= nbsp;  0.154088] [<fffffc00080d8e80>] flush_work+0x54/0x140=0A
> [    0.154092] [<fffffc0008166a0c>] lr= u_add_drain_all+0x138/0x188
=0A
> [    0.154097= ] [<fffffc00081ab2dc>] migrate_prep+0xc/0x18
=0A
> [&nbs= p;   0.154101] [<fffffc0008160e88>] alloc_contig_range+0xf= 4/0x350
=0A
> [    0.154105] [<fffffc00081bc= ef8>] cma_alloc+0xec/0x1e4
=0A
> [    0.1541= 10] [<fffffc0008446ad0>] dma_alloc_from_contiguous+0x38/0x40
= =0A
> [    0.154114] [<fffffc00080a093c>] __dm= a_alloc+0x74/0x25c
=0A
> [    0.154119] [<ff= fffc00084828d8>] nvme_alloc_queue+0xcc/0x36c
=0A
> [ &= nbsp;  0.154123] [<fffffc0008484b2c>] nvme_reset_work+0x5c4/0xd= a8
=0A
> [    0.154128] [<fffffc00080d9528&g= t;] process_one_work+0x128/0x2ec
=0A
> [    0.1= 54132] [<fffffc00080d9744>] worker_thread+0x58/0x434
=0A
&g= t; [    0.154136] [<fffffc00080df0ec>] kthread+0xd4/0= xe8
=0A
> [    0.154141] [<fffffc0008093ac0&= gt;] ret_from_fork+0x10/0x50
=0A
 
=0A
The lru drai= n work is scheduled on the system work queue, which is not
=0A
us= ed for memory reclaim. But this work is used for swap, so maybe it
= =0A
should be scheduled on a such a work queue, and this warning would= go
=0A
away. Unless there's a reason not to have a system memory= reclaim work
=0A
queue, I'll look into that.
=0A
 =
=0A
> But the log only explained why changed to workqueue ins= tead of schedule_work,
=0A
> no comments why use alloc_workqu= eue instead of create_singlethread_workqueue,
=0A
> though =0A
 
=0A
We removed single threaded work queues so m= ultiple controllers can be
=0A
probed in parallel.
=0A
&= nbsp;
=0A
>        "The ori= ginal create_*workqueue() functions are deprecated and scheduled for remov= al."
=0A
> (Documentation/workqueue.txt; https://patchwork.oz= labs.org/patch/575570/).
=0A
>
=0A
> The key poi= nt is "__WQ_LEGACY" was dropped.
=0A
> If I change to use "nv= me_workq =3D create_singlethread_workqueue("nvme");",  then no
= =0A
> warning on NVME probe in my case.
=0A
>
=0A=
> My question is, why you decide drop the flag "__WQ_LEGACY" for n= vme_workq?
=0A
 
=0A
I didn't decide to drop this. = The flag is used for deprecated usage,
=0A
but this is new usage.=
=0A
 
=0A
I think the real issue is nvme uses a WQ= _MEM_RECLAIM work queue but swap
=0A
does not. One of these proba= bly needs to change.
=0A
 
=0A
____________________= ___________________________
=0A
Linux-nvme mailing list
=0A<= div>Linux-nvme@lists.infradead.org
=0A
http://lists.infradead.org= /mailman/listinfo/linux-nvme
=0A
 
=0A

Regards,
Sheng-Hui


=0A
------=_001_NextPart033558812640_=------ -- 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