Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <77b99722-fc13-e5c5-c9be-7d4f3830859c@amd.com>
Date:   Thu, 9 Jun 2022 14:16:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Content-Language: en-US
To:     Michal Hocko <mhocko@suse.com>,
        =?UTF-8?Q?Christian_K=c3=b6nig?= <ckoenig.leichtzumerken@gmail.com>
Cc:     linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
        intel-gfx@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
        nouveau@lists.freedesktop.org, linux-tegra@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
        alexander.deucher@amd.com, daniel@ffwll.ch,
        viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
        hughd@google.com, andrey.grodzovsky@amd.com
References: <20220531100007.174649-1-christian.koenig@amd.com>
 <20220531100007.174649-4-christian.koenig@amd.com>
 <YqG67sox6L64E6wV@dhcp22.suse.cz>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
In-Reply-To: <YqG67sox6L64E6wV@dhcp22.suse.cz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SDNqbVlQb2FoaStTVXVSN0orMTJ6alFKeWdNZXR4MjFTbHVFbVBsUUpuWEpk?=
 =?utf-8?B?a2tlMHZuYzBsN1FoaS9WcjlnMWhxMFVnOXg4SWJqcXZ2b3Yyc1l4TmhweW5k?=
 =?utf-8?B?cHJxcFp0THdZc2RyK0FPeDd5WkFkWWpLTFZaNHlIU2FOQkJCWkIyM0kxdjBV?=
 =?utf-8?B?cEVGeHdZUUFlaHhubEg4OG0vUW16UDAyb212MUIvN0tNMkVmdXVROHhkRjBj?=
 =?utf-8?B?T3ZTMTJsRXpmbWFKZld5RkcvRVJBVzhjdmJ3VTZjTDhQYWx5bjJ5eGR5WHVs?=
 =?utf-8?B?QUZVUFJBay9jOTYxdkhrR0E5eUo0ZkN3TTFpZ2tNMWc1VXVFWHJ5aUFjYVMy?=
 =?utf-8?B?WEw1dWR6bHc0OE56K1k2YmlpdTdwSUZXZWwyWWN4VmlKRnV5bE9EU2c1Sk00?=
 =?utf-8?B?bVAvc3EyZXYrYlE3Z2tobWwrUEo0RVpYbXdSRzBJWjh5SWxtR3hZUkxMblcz?=
 =?utf-8?B?ekg4OTRkdDdReGpDYkcrOXQ2ZGs1MU9tV1hCZGs2Nk9hbkRFWk1wVk5UaTd5?=
 =?utf-8?B?ajZEU2xENGg0SXFLMm1WK0RCVkxLbEhzRE1xWlRlcU1vMUZ5SGh1blcxbG1X?=
 =?utf-8?B?eHIrRkVCK3Zlei8xVFlzVVh4Z3RwSGFBZDRvRDc3dnpka09vcldyeGphaDN0?=
 =?utf-8?B?TzdRdWt2eWJoTEcrTkJVK3ZDZ09PWldBTlROalhkZ1JMbVBwaHlwWEZTMVJt?=
 =?utf-8?B?d2RzbVExVkRGeEJpVE9oc3pPQ0ZyWG1tUnpMZml0SENlajdKbXZRMjFNWG52?=
 =?utf-8?B?VUduamRCMm9GbVJlSWxKWXNaUWI4S1M0bkJGYVRaUFk3K3VBK08waWdvR2Zs?=
 =?utf-8?B?TWszSHVlZS9XMWZFMDRBcE9qZjVMTFNGNGMxNUt5Vm1sWTFCOEVnU3hlL0Q3?=
 =?utf-8?B?b0xTemJrSXRmREY4c1RDdzdtTkNiVHhxT0tQQ0dlQ0RKZ0lhTkM5QjZpQ3RB?=
 =?utf-8?B?NWdCazdWTFlIeTA5UjJicFpuelNWZ1BFU0dTNWtodEh4dmd2TkdoL0dkdnZo?=
 =?utf-8?B?S2IxZDJta2ljN1owaTdTSlFsQjBSMG0vVGd5RCt5ZGVhUVk2MUhqelZHMk4w?=
 =?utf-8?B?ZjNMQUNmaXJkOTA0OHo0OWpuTWNuRzZFQytsTmM2eE1PWnJVTnU4MVNkczhk?=
 =?utf-8?B?MXJIVDI2RkdHcyt3Q3NJRnpFY0pzMzkrekRaV2hnQktXeFExZEhIT2xyS1Zh?=
 =?utf-8?B?Um5hNmtXWTl0YzNTMnVzU05qVUFrUEsrMlVza2xQUThDOTE5OXhmc2IvQ1A0?=
 =?utf-8?B?bXpqSm5nbUhPRWJUbXMvbU5pSWJpTUdiRnBLalN1UUttOFZ4ZWQxV3ZwZUFD?=
 =?utf-8?B?YXhlaDVVSWZwMTd3OUMvd0RVcEFYcVUwNEdsNm9JUHRhQ2tNZWE4NGRHTi9s?=
 =?utf-8?B?YmR5ekpKZ1RZaHcxazNxYUsvSVJjVi80RUdaUnJ0aXEwSmZXcmV5MTFQSnAz?=
 =?utf-8?B?WnpFVGhpc1E1M2trek5PanhtbzhlM1dyK1IrV1loRGVjc2JRWHFmV1lSbTlJ?=
 =?utf-8?B?Wm50OC8rVmM4SVF4YkFuRGI2M1V4VXBObVJ3SDlTcGt0TlA1cDQxRE1WWElh?=
 =?utf-8?B?WUZMVksyeVB5MElrcUd6YWtCT3dYc2JvMDNhR3VGTHV4bC9tSVdraHp1QktM?=
 =?utf-8?B?eVFVNnJhZ0huNGtmenNKdDhFcDNORGdzUjZ6TEQ1VG1lRkFlbWxXVlhIZmJV?=
 =?utf-8?B?ZG1sckN1NlA0RjkxSkpKODVLK0JGWUV5SDloRXZOb1puZytjT0xxcm5EOHp4?=
 =?utf-8?B?RU5vR1NjdGNNVWlYalVJK1JyQjV3SkdIaWUxODhuMUQvM3FTRWs5RVJWRHNR?=
 =?utf-8?B?dGJ4RnJXM3hQanIxdzhMK0UxZTArRExFeEl0YmlnWS9YMUdZeWJIMU0xMmFh?=
 =?utf-8?B?ZFFWaW56Q1FaS21MYXRSVDVyb25LY09DMFRyRnNVTWJHQkZ6dnROdGZFcitW?=
 =?utf-8?B?V1p6ZkN4SU1WVllsTWMvajYvSHpLVjloUXZKVkpmNi90eUlheHBSb3E0bnpU?=
 =?utf-8?B?eGFaMzVVM0pzZVhnb3pjVWJOQUhKaTVDdHBBeS9nOVY0Qk9iWGtpOUZ4UzUw?=
 =?utf-8?B?M1BGQStMeG9XMHdFa01PQm1ZVDJuVTM1VGtnR29kS203VmNrZHdERDliaXky?=
 =?utf-8?B?ZmxKSThRVU5XdCtVSlZFSEtZQ1kvK1lCSVpxdWdWMkIzWU1rdk5HSlI0ZEgy?=
 =?utf-8?B?RStFd1BTQ2VFL3R3NnMyVXVvRlFsU2Y0MEx6YnZ4L1gxNDZwZERCc3JaM3E4?=
 =?utf-8?B?M1IzbHBraXdySUhlZ1FVRnBaSWpsVUVIVWdCU2drcFV6aHByUFhic25FWXhp?=
 =?utf-8?B?ajBEeFM0UU9Tdm1pVUpZbGU4OVZUcnRxVkpSdWpYWVArRGlYWnZoQzQ4TjRt?=
 =?utf-8?Q?4a35nrjAFGg5czGovXu2jkhq74+LnZju4sOkA3ETXU2Hu?=
X-MS-Exchange-AntiSpam-MessageData-1: nUUj7FIWfvqV1A==
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 83a2d231-6bbd-4a12-7263-08da4a11f651
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3587.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2022 12:17:03.6434
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 45k76p0B/TLKx/YAjEiRq55YehYfWN1Wm4WNxfSQtUV7pfGR/SotvC632uXEpVkw
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4617
X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE,
        URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Am 09.06.22 um 11:18 schrieb Michal Hocko:
> On Tue 31-05-22 11:59:57, Christian König wrote:
>> This gives the OOM killer an additional hint which processes are
>> referencing shmem files with potentially no other accounting for them.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   mm/shmem.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index 4b2fea33158e..a4ad92a16968 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -2179,6 +2179,11 @@ unsigned long shmem_get_unmapped_area(struct file *file,
>>   	return inflated_addr;
>>   }
>>   
>> +static long shmem_oom_badness(struct file *file)
>> +{
>> +	return i_size_read(file_inode(file)) >> PAGE_SHIFT;
>> +}
> This doesn't really represent the in memory size of the file, does it?

Well the file could be partially or fully swapped out as anonymous 
memory or the address space only sparse populated, but even then just 
using the file size as OOM badness sounded like the most straightforward 
approach to me.

What could happen is that the file is also mmaped and we double account.

> Also the memcg oom handling could be considerably skewed if the file was
> shared between more memcgs.

Yes, and that's one of the reasons why I didn't touched the memcg by 
this and only affected the classic OOM killer.

Thanks for the comments,
Christian.