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=-13.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 6EE1EC433DB for ; Fri, 5 Feb 2021 03:39:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C29BD64FB3 for ; Fri, 5 Feb 2021 03:39:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C29BD64FB3 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 06E3D6B0005; Thu, 4 Feb 2021 22:39:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 01E7A6B006C; Thu, 4 Feb 2021 22:39:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E765A6B006E; Thu, 4 Feb 2021 22:39:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D13066B0005 for ; Thu, 4 Feb 2021 22:39:33 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 944D01F06 for ; Fri, 5 Feb 2021 03:39:33 +0000 (UTC) X-FDA: 77782809426.30.talk49_310e4bb275e1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 79C8E180B3C83 for ; Fri, 5 Feb 2021 03:39:33 +0000 (UTC) X-HE-Tag: talk49_310e4bb275e1 X-Filterd-Recvd-Size: 7148 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Fri, 5 Feb 2021 03:39:32 +0000 (UTC) Received: by mail-wm1-f43.google.com with SMTP id t142so2674485wmt.1 for ; Thu, 04 Feb 2021 19:39:32 -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:content-transfer-encoding; bh=EdjLgTFEfuQJGZBK+nXnyy4MdoUmVzeK7aTpj4p2cVs=; b=G0PEitJ+usd81lX6EDaRByi5sRj40yJPc5uhcY6QEK2X9Wq/MFm/0TXDN4RVz4ZQ6A ul/qH0mY8Lsr3XrIXuQOWFAtdI0BS6f2CpejnwFRIr29LWuWTbar+iE+BI3jzBNT/8pz bN4/D1zo8nWzktWb4bINMtYivhqcbzqgdnInQZ/8/0sEewECFyCYy640waGWJY0G1pqw Cm3UCGiNdKrJ6Z6enQVnga+JRIGdwAuAA2hDqGOY/AMehsv5k1ZgBGklnwlaTS/3abdO m/3btPqZdflTc78uLwP6rbg6URCpuKVpD+NEZtDZBBCapZrQXXYqV4CSKeCEy6/4DkV2 uZhA== 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=EdjLgTFEfuQJGZBK+nXnyy4MdoUmVzeK7aTpj4p2cVs=; b=C4PMe/rdzvUp6za/qTQKwQzGZeUuoz3BUGHCW7ZgXFdljEPJCoZrENUpXC3QLmc429 8+5D5nMDzW6eo9PoCY1g0z+748LFqhGWLBf1Z74EP1D9VnnKhhRxDnD0xcoycZvbflAJ RRRoX6Eq0EoUnFxgQhd4vPlZIe7Zx2tIRzLxLPOrLtAwI8X6bnOzcURzsenPnibPyLbN MWV+MuFaCVFviJAfCYUaOSyw2Z9Sq+4jvhiKmIEzTDtKL57ND62sdGzYj3ipgMBjGlE/ QNLAhJOrmECAaBdIdKLMZFa0vDE0uHjVI/sPOp6OkpCoEXqfkdaym0t0oC2oCd0qcInu jqEw== X-Gm-Message-State: AOAM532kPmyeWHKlZd97/S9LZbNIx78J6UzIu2B9BtGPDgM8SRfyN5KA dtU9l0YktCmgKJC7i3aYrLqhmjed25HiwWtUFiv11g== X-Google-Smtp-Source: ABdhPJwQJDGTRMEZ//zE5/HAppxy72r/wRamcStzdUixQgW9nAir2xq28+kgXZDBfrH14dhfKQY0nMy71MkA5Gx9FJg= X-Received: by 2002:a05:600c:4fcb:: with SMTP id o11mr1704797wmq.88.1612496371382; Thu, 04 Feb 2021 19:39:31 -0800 (PST) MIME-Version: 1.0 References: <20210203003134.2422308-1-surenb@google.com> <20210203015553.GX308988@casper.infradead.org> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 4 Feb 2021 19:39:20 -0800 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: Alex Deucher Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , 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 7:55 AM Alex Deucher wrote: > > 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 struc= t > > >>> 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 wou= ld > > >> 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 pointe= d 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 pointer= s > > 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 bus= y > > to dig them up. > > https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.ht= ml > I think there was a more recent discussion, but I can't seem to find it. Thanks for the pointer! Appreciate the time everyone took to explain the issues. Thanks, Suren. > > 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