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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=unavailable 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 4700DC63798 for ; Wed, 25 Nov 2020 15:31:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D077F206C0 for ; Wed, 25 Nov 2020 15:31:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="NnonjqDm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730282AbgKYPax (ORCPT ); Wed, 25 Nov 2020 10:30:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730214AbgKYPax (ORCPT ); Wed, 25 Nov 2020 10:30:53 -0500 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4EA59C061A4F for ; Wed, 25 Nov 2020 07:30:40 -0800 (PST) Received: by mail-lj1-x244.google.com with SMTP id b17so2690489ljf.12 for ; Wed, 25 Nov 2020 07:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Slyp8M32CTo3TZBPXXq3KE8TAXlfyjLtOZIfe4y0/HM=; b=NnonjqDmdvZd/9bSd04OInTnpLaptAn24qZ62do7ESFB5eB8H99OFXgxMq0C0/XXt7 WBVm0g1C8mVKkGzY594+h7Rr+u73Edked79ouedKZIUISNROONMwbnsYE9BWo27EESIz RY94ivrBRdtIIoBGdN6TF2EnUQfqce8rm8OcNjSJexupkBAZAYwcK/Zhjl45Tkk34cu0 RCsJZnIqjYVRIHhtqINp47mSXVwVOoEZ45cbbCOAPETWDmpmyM5XNzRK0YjOCpAp3ogW UYsyRRKvgdc+uwClcNu8ktg2uLyko2UN1P0idwia0Ilbl0SHABEocGwnry2I192Hn/K2 Z3+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Slyp8M32CTo3TZBPXXq3KE8TAXlfyjLtOZIfe4y0/HM=; b=VQkFMucwepFJl14QJ+DIk9P6MVxv9IxS+pOwHB6jF+IxqBS8Az5ur5Jyl99uZwwKqK zaKnnIs3/6cpGZ9Mh9nyUxshTHDj4tI34Uc4DMrWbGjEA/3W9B7g3UtBYYbOB6ssnhAS Ga4oPfLKFYLVEyYITgeun1ZLssS0sLbL5ZRUIOFHWIyZeUg5FPIt2pM80An/ta/KRkbr cscpvAWuz/faeHk4hWigDzbQjnPc0AtaR9iR8RoEl/05uJfmL0Cx10pbaW4N+tTfGcHC i4iksW5ZV5kE8fhTDrIUkb6Ic85blM35z2owyntLxWRxTQI47T+UDmFFuzqy8JIizfV4 V5uw== X-Gm-Message-State: AOAM532J2gNzxeG36wYzsqEOwlPB/ZVEC2LlVpiKQMxGIasY/DCv3KKi t6jNSuFKvHGWF7cgdEqRKNmvwGS0ZlsHlCnmeiNw1Q== X-Google-Smtp-Source: ABdhPJwVzS1M6/iPBLepZWnkrgJKe9xWN8z9BuRiNQ1/W7SbWt/76jTFn5FM03QWJvBNkwwAfM9dHSjIgzvQnH95Cc0= X-Received: by 2002:a2e:3c12:: with SMTP id j18mr1598680lja.192.1606318238459; Wed, 25 Nov 2020 07:30:38 -0800 (PST) MIME-Version: 1.0 References: <20201020085940.13875-1-sjpark@amazon.com> <20201020085940.13875-8-sjpark@amazon.com> In-Reply-To: <20201020085940.13875-8-sjpark@amazon.com> From: Shakeel Butt Date: Wed, 25 Nov 2020 07:30:27 -0800 Message-ID: Subject: Re: [PATCH v22 07/18] mm/page_idle: Avoid interferences from concurrent users To: SeongJae Park Cc: Andrew Morton , SeongJae Park , Jonathan.Cameron@huawei.com, Andrea Arcangeli , acme@kernel.org, alexander.shishkin@linux.intel.com, amit@kernel.org, benh@kernel.crashing.org, brendan.d.gregg@gmail.com, Brendan Higgins , Qian Cai , Colin Ian King , Jonathan Corbet , David Hildenbrand , dwmw@amazon.com, Marco Elver , "Du, Fan" , foersleo@amazon.de, Greg Thelen , Ian Rogers , jolsa@redhat.com, "Kirill A. Shutemov" , Mark Rutland , Mel Gorman , Minchan Kim , Ingo Molnar , namhyung@kernel.org, "Peter Zijlstra (Intel)" , Randy Dunlap , Rik van Riel , David Rientjes , Steven Rostedt , Mike Rapoport , sblbir@amazon.com, Shuah Khan , sj38.park@gmail.com, snu@amazon.de, Vlastimil Babka , Vladimir Davydov , Yang Shi , Huang Ying , zgf574564920@gmail.com, linux-damon@amazon.com, Linux MM , linux-doc@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 20, 2020 at 2:06 AM SeongJae Park wrote: > > From: SeongJae Park > > Concurrent Idle Page Tracking users can interfere each other because the > interface doesn't provide a central rule for synchronization between the > users. Users could implement their own synchronization rule, but even > in that case, applications developed by different users would not know > how to synchronize with others. To help this situation, this commit > introduces a centralized synchronization infrastructure of Idle Page > Tracking. > > In detail, this commit introduces a mutex lock for Idle Page Tracking, > called 'page_idle_lock'. It is exposed to user space via a new bool > sysfs file, '/sys/kernel/mm/page_idle/lock'. By writing to and reading > from the file, users can hold/release and read status of the mutex. > Writes to the Idle Page Tracking 'bitmap' file fails if the lock is not > held, while reads of the file can be done regardless of the lock status. > > Note that users could still interfere each other if they abuse this > locking rule. Nevertheless, this change will let them notice the rule. > > Signed-off-by: SeongJae Park I don't think this is allowed. I mean returning to user space with held mutex and other processes can unlock it. I don't think mutex is what you need. Or more importantly is this really an issue? 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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=unavailable 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 57BDCC64E7C for ; Wed, 25 Nov 2020 15:30:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BDA262087C for ; Wed, 25 Nov 2020 15:30:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="NnonjqDm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BDA262087C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4B5776B0082; Wed, 25 Nov 2020 10:30:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 43CF96B0083; Wed, 25 Nov 2020 10:30:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32D146B0085; Wed, 25 Nov 2020 10:30:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) by kanga.kvack.org (Postfix) with ESMTP id 148246B0082 for ; Wed, 25 Nov 2020 10:30:42 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2A3DB3620 for ; Wed, 25 Nov 2020 15:30:41 +0000 (UTC) X-FDA: 77523327882.12.meat72_3c0b85627377 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id C13D718028B7E for ; Wed, 25 Nov 2020 15:30:40 +0000 (UTC) X-HE-Tag: meat72_3c0b85627377 X-Filterd-Recvd-Size: 5478 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Wed, 25 Nov 2020 15:30:40 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id z1so2727185ljn.4 for ; Wed, 25 Nov 2020 07:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Slyp8M32CTo3TZBPXXq3KE8TAXlfyjLtOZIfe4y0/HM=; b=NnonjqDmdvZd/9bSd04OInTnpLaptAn24qZ62do7ESFB5eB8H99OFXgxMq0C0/XXt7 WBVm0g1C8mVKkGzY594+h7Rr+u73Edked79ouedKZIUISNROONMwbnsYE9BWo27EESIz RY94ivrBRdtIIoBGdN6TF2EnUQfqce8rm8OcNjSJexupkBAZAYwcK/Zhjl45Tkk34cu0 RCsJZnIqjYVRIHhtqINp47mSXVwVOoEZ45cbbCOAPETWDmpmyM5XNzRK0YjOCpAp3ogW UYsyRRKvgdc+uwClcNu8ktg2uLyko2UN1P0idwia0Ilbl0SHABEocGwnry2I192Hn/K2 Z3+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Slyp8M32CTo3TZBPXXq3KE8TAXlfyjLtOZIfe4y0/HM=; b=GX6N+/aitVNAKDQ9VE6ojGPax1mD7auUduZ6KoQTzAFsPXQZN5H32lD3WywUaBcPZc Ghff7OkDyT24PLiagPRMTZ/kXty3yDvTOM7K6QesmlfoydCY/3P6giSiJLdk2v5HzmhR Mhs87D/gaqXY3bNHWak5cI+Uwx8xzon1+XlSA+SEvO1Mtsx3S17+9yjXC5nKdximXpbQ ia/RJjYQLxq0Uf5OeKT6qq1tBjHqtASVcGnZ62Pc4VKjTncEK0ndvP4QUcqN/8oypz80 gpYHYt0R/SjBJ2gS66V2wTpwITSIvAwNnfa9mdMvFhtHRCy9lgQAOQ+921HqjsAG1+Hy ZMuA== X-Gm-Message-State: AOAM533895cNiXDY65XA3CY3GeixV4uagEkcOgHMVwzrQTHUEEPmee1w sZjfJG6M0NwtRg6UmVVR2LL0TOcWUy1QrGxbIwPzUg== X-Google-Smtp-Source: ABdhPJwVzS1M6/iPBLepZWnkrgJKe9xWN8z9BuRiNQ1/W7SbWt/76jTFn5FM03QWJvBNkwwAfM9dHSjIgzvQnH95Cc0= X-Received: by 2002:a2e:3c12:: with SMTP id j18mr1598680lja.192.1606318238459; Wed, 25 Nov 2020 07:30:38 -0800 (PST) MIME-Version: 1.0 References: <20201020085940.13875-1-sjpark@amazon.com> <20201020085940.13875-8-sjpark@amazon.com> In-Reply-To: <20201020085940.13875-8-sjpark@amazon.com> From: Shakeel Butt Date: Wed, 25 Nov 2020 07:30:27 -0800 Message-ID: Subject: Re: [PATCH v22 07/18] mm/page_idle: Avoid interferences from concurrent users To: SeongJae Park Cc: Andrew Morton , SeongJae Park , Jonathan.Cameron@huawei.com, Andrea Arcangeli , acme@kernel.org, alexander.shishkin@linux.intel.com, amit@kernel.org, benh@kernel.crashing.org, brendan.d.gregg@gmail.com, Brendan Higgins , Qian Cai , Colin Ian King , Jonathan Corbet , David Hildenbrand , dwmw@amazon.com, Marco Elver , "Du, Fan" , foersleo@amazon.de, Greg Thelen , Ian Rogers , jolsa@redhat.com, "Kirill A. Shutemov" , Mark Rutland , Mel Gorman , Minchan Kim , Ingo Molnar , namhyung@kernel.org, "Peter Zijlstra (Intel)" , Randy Dunlap , Rik van Riel , David Rientjes , Steven Rostedt , Mike Rapoport , sblbir@amazon.com, Shuah Khan , sj38.park@gmail.com, snu@amazon.de, Vlastimil Babka , Vladimir Davydov , Yang Shi , Huang Ying , zgf574564920@gmail.com, linux-damon@amazon.com, Linux MM , linux-doc@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" 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 Tue, Oct 20, 2020 at 2:06 AM SeongJae Park wrote: > > From: SeongJae Park > > Concurrent Idle Page Tracking users can interfere each other because the > interface doesn't provide a central rule for synchronization between the > users. Users could implement their own synchronization rule, but even > in that case, applications developed by different users would not know > how to synchronize with others. To help this situation, this commit > introduces a centralized synchronization infrastructure of Idle Page > Tracking. > > In detail, this commit introduces a mutex lock for Idle Page Tracking, > called 'page_idle_lock'. It is exposed to user space via a new bool > sysfs file, '/sys/kernel/mm/page_idle/lock'. By writing to and reading > from the file, users can hold/release and read status of the mutex. > Writes to the Idle Page Tracking 'bitmap' file fails if the lock is not > held, while reads of the file can be done regardless of the lock status. > > Note that users could still interfere each other if they abuse this > locking rule. Nevertheless, this change will let them notice the rule. > > Signed-off-by: SeongJae Park I don't think this is allowed. I mean returning to user space with held mutex and other processes can unlock it. I don't think mutex is what you need. Or more importantly is this really an issue?