Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp466198pxu; Wed, 25 Nov 2020 07:36:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJzmg78LjOwVy0BvolSquUZR5qrVbGy2sF3Lf4xR4shwGF+DIA8o/ZeaDxMA1oqHs25eVe5P X-Received: by 2002:a50:f198:: with SMTP id x24mr3863754edl.255.1606318605911; Wed, 25 Nov 2020 07:36:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606318605; cv=none; d=google.com; s=arc-20160816; b=CnrJePlGXMe0XPPBXIf6FvGhxwXYp/JChV+ea5j434JhW4mAaXbrfAZJ9opyba2OYB Od2aNLwKWO6fiRGvEcASTZVhzI0CIqeimz08gf315KgHoi5n3VrIxp82Yf5UPTbeoQ4J kK2NT9lfrmItWeyCHG2tXkPNR1MnyiHuIG0chtimn1yeo1ejp0AIq3pR++jH75y583SB s+aO/qufKlSSmo2/u0lJ4yc8gX4dY0xPX8Xp3b+Ql1FLCqZhc581/MhGP0swa/sZJ66Z Lj57pCjRJnZ2HXQngkfv0mJ9iHcG4ixkuG0rHwh3K5qXy+zy/N6mD0uHX69t/Zng7SSS +mQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Slyp8M32CTo3TZBPXXq3KE8TAXlfyjLtOZIfe4y0/HM=; b=dnkKGXnb4mJ33qgprrVA/9D6Tl4UZEuIgCOdwLMDW26qPOAEhHAz09L2fj7z65nqdk aUKZ+hnIxnadBBeEf8yJFUNiQc/IEOztMxM3HLVgJEo7c5+yWAPq+/+Qnve8dblKE+JE 1fZY2GkQ37VEiUM6DP+BbGjx5BTBu1aoGtAhGlY8jPYwnoRKPhVnSb6zQIHqmVP8RLY9 b3VKSowwC3ghHWruSgKk78LwlY2n9/P0OTswEBuky4x5a0ndxBvez+c+ojLcviQ/2h9s 50wJZFk7VCDboOTuLx/o44qG3kvAwRRZBMC3BdtbyCuRXM6rc9DND7xVNdzB9qqXUzd8 1sxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=NnonjqDm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q26si1459323ejb.105.2020.11.25.07.36.22; Wed, 25 Nov 2020 07:36:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=NnonjqDm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730275AbgKYPax (ORCPT + 99 others); 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-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?