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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 161BEC433DB for ; Thu, 4 Feb 2021 15:55:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7405F64F5C for ; Thu, 4 Feb 2021 15:55:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7405F64F5C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C62E86B0006; Thu, 4 Feb 2021 10:55:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BEBD66B007E; Thu, 4 Feb 2021 10:55:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ADA2D6B0080; Thu, 4 Feb 2021 10:55:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0210.hostedemail.com [216.40.44.210]) by kanga.kvack.org (Postfix) with ESMTP id 9506E6B0006 for ; Thu, 4 Feb 2021 10:55:00 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 5B0011EFF for ; Thu, 4 Feb 2021 15:55:00 +0000 (UTC) X-FDA: 77781033960.27.drug57_280e67f275dd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 3F6B43D663 for ; Thu, 4 Feb 2021 15:55:00 +0000 (UTC) X-HE-Tag: drug57_280e67f275dd X-Filterd-Recvd-Size: 6719 Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Thu, 4 Feb 2021 15:54:59 +0000 (UTC) Received: by mail-oi1-f181.google.com with SMTP id k142so4163167oib.7 for ; Thu, 04 Feb 2021 07:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TE+20LCg4P7JDuDi9T+hP1y0ckG6wCABKFlMFLlaYRg=; b=I9K7YZxnalNA46Wh5Hx77j97EmE2tjIuMHosJXXvSw3CyZGysR/AJ/IBWQPzW44qW4 erlX+94l1WSwG+/6XrZWbyZ9arxJmxCnM4PXgEbRYO4Drz109iHQ4dhFQv0R3eH+KETa UP/yIQL9L1KgoghJ92Ou9IqHzvzuBjvJZboPtUTdpLOyJEmxsW4InealPG0o0if7HvN0 JfRVp1+UN2Tc5FI2T5zhrKuqCxBUmGXsIqeDEnTJaNrAj4B/PgDat1cbzb7WGGbUN1Bz wJy5inN4ewT1q6TRNC/gLPX5fyIzRFULylh2apOjMENakVXi+96KpaIP9zRmPRTe0BUT 6U4g== 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:content-transfer-encoding; bh=TE+20LCg4P7JDuDi9T+hP1y0ckG6wCABKFlMFLlaYRg=; b=VdeLVD3oJOHM6hMhi3deFDl+7lBUtwYDu8PJoxSixh+m90Fl5JxXofolHn+RJngWiJ iox2boWrIwzai/FpTTTw1dIGd51n3SoE/XsrAQ7OwoLLF1Rwk5KP7KmXnMp/OfatuzuF d+xJDgpyowHiNzu7mgHgzWJ9G5w3B6NcDagVgT/zgtSTJMUL1coUsW5DGONsQsW5GZzF 1Ym3g0RPYgKwgnUp91tRK8nAMEu0KZDjzqZsg5qu7Y0OM7ZlX8PLCCGUdlbIOXYq5BCG b224DpYq5NemyqkOKpyNx3SLawaKY9B+MyJh4ZchvEUCjiUxsXY78quM32Tt+Hg/ZpP4 2OnA== X-Gm-Message-State: AOAM532qVNpzE7DORU7POH0WAe39nRC/kHJXbSzn3RDpr5+yVY6ScU0u UR04nR9c5BChAy8t9G6RfbKu8V4Qbp1J4rdiDik= X-Google-Smtp-Source: ABdhPJyHWaV6uURhsSn77dEppvf6IL/58QKDwEfT10ywtTObf87RA9Zbd2LVs5T02SCrHGMuhdJx0KX4chS3d+eTHNI= X-Received: by 2002:aca:1a17:: with SMTP id a23mr50294oia.120.1612454099140; Thu, 04 Feb 2021 07:54:59 -0800 (PST) MIME-Version: 1.0 References: <20210203003134.2422308-1-surenb@google.com> <20210203015553.GX308988@casper.infradead.org> In-Reply-To: From: Alex Deucher Date: Thu, 4 Feb 2021 10:54:48 -0500 Message-ID: Subject: Re: [Linaro-mm-sig] [PATCH 1/2] mm: replace BUG_ON in vm_insert_page with a return of an error To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: Suren Baghdasaryan , Daniel Vetter , Christoph Hellwig , Sandeep Patil , dri-devel , Linux MM , Robin Murphy , James Jones , Linux Kernel Mailing List , Matthew Wilcox , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Minchan Kim , Liam Mark , Chris Goldsworthy , Hridya Valsaraju , Andrew Morton , Android Kernel Team , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thu, Feb 4, 2021 at 3:16 AM Christian K=C3=B6nig wrote: > > Am 03.02.21 um 22:41 schrieb Suren Baghdasaryan: > > [SNIP] > >>> How many semi-unrelated buffer accounting schemes does google come up= with? > >>> > >>> We're at three with this one. > >>> > >>> And also we _cannot_ required that all dma-bufs are backed by struct > >>> page, so requiring struct page to make this work is a no-go. > >>> > >>> Second, we do not want to all get_user_pages and friends to work on > >>> dma-buf, it causes all kinds of pain. Yes on SoC where dma-buf are > >>> exclusively in system memory you can maybe get away with this, but > >>> dma-buf is supposed to work in more places than just Android SoCs. > >> I just realized that vm_inser_page doesn't even work for CMA, it would > >> upset get_user_pages pretty badly - you're trying to pin a page in > >> ZONE_MOVEABLE but you can't move it because it's rather special. > >> VM_SPECIAL is exactly meant to catch this stuff. > > Thanks for the input, Daniel! Let me think about the cases you pointed = out. > > > > IMHO, the issue with PSS is the difficulty of calculating this metric > > without struct page usage. I don't think that problem becomes easier > > if we use cgroups or any other API. I wanted to enable existing PSS > > calculation mechanisms for the dmabufs known to be backed by struct > > pages (since we know how the heap allocated that memory), but sounds > > like this would lead to problems that I did not consider. > > Yeah, using struct page indeed won't work. We discussed that multiple > times now and Daniel even has a patch to mangle the struct page pointers > inside the sg_table object to prevent abuse in that direction. > > On the other hand I totally agree that we need to do something on this > side which goes beyong what cgroups provide. > > A few years ago I came up with patches to improve the OOM killer to > include resources bound to the processes through file descriptors. I > unfortunately can't find them of hand any more and I'm currently to busy > to dig them up. https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html I think there was a more recent discussion, but I can't seem to find it. Alex > > In general I think we need to make it possible that both the in kernel > OOM killer as well as userspace processes and handlers have access to > that kind of data. > > The fdinfo approach as suggested in the other thread sounds like the > easiest solution to me. > > Regards, > Christian. > > > Thanks, > > Suren. > > > > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel