From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0074C43331 for ; Sat, 28 Mar 2020 00:17:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 52034206E6 for ; Sat, 28 Mar 2020 00:17:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="tE2x0AnF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 52034206E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C48866B0010; Fri, 27 Mar 2020 20:17:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF8ED6B0032; Fri, 27 Mar 2020 20:17:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC0606B0036; Fri, 27 Mar 2020 20:17:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 920EA6B0010 for ; Fri, 27 Mar 2020 20:17:22 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 56A19180AD80F for ; Sat, 28 Mar 2020 00:17:22 +0000 (UTC) X-FDA: 76642856724.11.floor34_5d5963c0a4843 X-HE-Tag: floor34_5d5963c0a4843 X-Filterd-Recvd-Size: 5334 Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Sat, 28 Mar 2020 00:17:21 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02S0ECts067141; Sat, 28 Mar 2020 00:17:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2020-01-29; bh=TkczSJTHT6DjomI7Gw7mr8sP9DJiwrHZ4XBhfGDHUog=; b=tE2x0AnFwkzquTjPYPJtSSUOTIUr5cRQKsQ6brqtxlZahHmQiWQDNndbDOlVL4RCJPHr rDFSGgqeERza5Cgh8aWadUkNKf0JpDP6ImP12/AkMx9+Z2AXtjfmhpDOVKYrdAtgavij fyFSq3maRkdaitDBud33m1ofY85n+ll+p0YVa4XjNssXfzj8aaRwkrnP6oAi8vBJV5Gw FfVQMyPnuyHcUUZPqBgFH0/9DCcmVbOgcKiav7bi8+CmhhsUY5ZNiL334z2u2klXxnD6 pbpcddjahDptASZ0UAYhMZaiTayoE65khSpAxJdCnOsE1n3x+6PgvmyxsQUlQ2WvFw7l LQ== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 301m49hyy1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 28 Mar 2020 00:17:19 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02S0BmQ3110319; Sat, 28 Mar 2020 00:17:19 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 3003gpy4q0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 28 Mar 2020 00:17:19 +0000 Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 02S0HGS6032130; Sat, 28 Mar 2020 00:17:17 GMT Received: from ca-dmjordan1.us.oracle.com (/10.211.9.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Mar 2020 17:17:16 -0700 Date: Fri, 27 Mar 2020 20:17:36 -0400 From: Daniel Jordan To: Shile Zhang Cc: Pavel Tatashin , Daniel Jordan , Andrew Morton , Kirill Tkhai , linux-mm , LKML Subject: Re: [PATCH v3] mm: fix tick timer stall during deferred page init Message-ID: <20200328001736.pxcnabxvrr3d6bty@ca-dmjordan1.us.oracle.com> References: <20200311123848.118638-1-shile.zhang@linux.alibaba.com> <20200319190512.cwnvgvv3upzcchkm@ca-dmjordan1.us.oracle.com> <20200326185822.6n56yl2llvdranur@ca-dmjordan1.us.oracle.com> <427ce795-0274-56e5-16e4-7be00c7145f7@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427ce795-0274-56e5-16e4-7be00c7145f7@linux.alibaba.com> User-Agent: NeoMutt/20180716 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9573 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 adultscore=0 spamscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003270199 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9573 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 clxscore=1015 bulkscore=0 impostorscore=0 suspectscore=0 spamscore=0 adultscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003270199 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Mar 27, 2020 at 12:39:18PM +0800, Shile Zhang wrote: > On 2020/3/27 03:36, Pavel Tatashin wrote: > > I agree with Daniel, we should look into approach where > > pgdat_resize_lock is taken only for the duration of updating tracking > > values such as pgdat->first_deferred_pfn (perhaps we would need to add > > another tracker that would show chunks that are currently being worked > > on). > > > > The vast duration of struct page initialization process should happen > > outside of this lock, and only be taken when we update globally seen > > data structures: lists, tracking variables. This way we can solve > > several problems: 1. allow interrupt threads to grow zones if > > required. 2. keep jiffies happy. 3. allow future scaling when we will > > add inner node threads to initialize struct pages (i.e. ktasks from > > Daniel). > > It make sense, looking forward to the inner node parallel init. > > @Daniel > Is there schedule about ktasks? Yep, and it's now padata multithreading instead of ktask since we already have 'task' in the kernel. Current plan is to start with users in the system context, that is those that don't require userland resource controls such as cgroup. So I'll post a new version of this timestamp fix pretty soon and then likely post a series that multithreads page init. Future work is tentatively doing other system users, remote charging for the CPU controller, and then users that can be accounted with cgroup etc.