Received: by 2002:a05:6a10:5594:0:0:0:0 with SMTP id ee20csp312778pxb; Mon, 25 Apr 2022 10:25:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTjvxru4JX5qTugzEfJweeKda0wuhfZMEh9KXnBdkcDmMKJBsIzNKjStgx7gv72WjeT5zy X-Received: by 2002:a05:6a00:c91:b0:50d:4f37:37df with SMTP id a17-20020a056a000c9100b0050d4f3737dfmr1005709pfv.66.1650907518212; Mon, 25 Apr 2022 10:25:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650907518; cv=none; d=google.com; s=arc-20160816; b=tAqY4Fvqah/hcIMrevQ8I8faoUxw+uwpZMjG4JevDmPICaAnKX4rWU4pCpMiM6iIe6 8Gv8O4eb4rA5zzNxsya3fk8wlwrv5ZDjHiRGmFcLBeKpji7EvzF7TYOpz6g6+MzjVwab ocpjuUKMb1xek40oCuaw7ACQMOg9VNWXWCzC0qIYSgtrGWy6dvNwAj4l7TKFD0WZYemg xBEZy9c71ca15zw73Re9inVF0kC5yqBODBWAom8L6XA835tGAz6oDXzvb18zabLA3y69 0gCFJ4/LGZyxIoMXXkKQfonxC1V2JplbSMcvyOhm0+n0iy11znXCOHaQx4vb8yj0T72C 25fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=pZLWDFS8RgdNHPorQYwwXOayoTTe55X/Bje9P63wXrs=; b=jbrNa4Gc8zuY0GhOFHOhH+JGkGoya7z5yVm/1yfqesqS5YNVm9tMx280GvJSSeKn59 qFhztyyC4MTqrPO2L3CX5Y12tgqU9PNbkOgpC2xNKBHXvpA46XofuaI50omNdvw3xTQU zV0H8VkRWAMBkCK6WFvmwo+b3NYVVhXP9OvPRdHzAhNX298f0kaUWhhvLvK4QDKayF1f LA8QibMC6X3DgBXBwgfwA4fYHsaKfyBGmsSI8aPff5yhgxPOA0jTKMBnBTL5K9oRiwjI AVrhgMH4g2wY76ujW0TvZLxn1HViIndAYsUsG/h6ScnAJUprDFrXXzuSFwCpzBnYPRb/ t3CA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="U4q32/rf"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b2-20020a170902b60200b0015c9f263ed8si8581407pls.179.2022.04.25.10.25.00; Mon, 25 Apr 2022 10:25:18 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="U4q32/rf"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S243027AbiDYPzf (ORCPT + 99 others); Mon, 25 Apr 2022 11:55:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53382 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240915AbiDYPz2 (ORCPT ); Mon, 25 Apr 2022 11:55:28 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C17D3A5CC for ; Mon, 25 Apr 2022 08:52:23 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id p12so21414582lfs.5 for ; Mon, 25 Apr 2022 08:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pZLWDFS8RgdNHPorQYwwXOayoTTe55X/Bje9P63wXrs=; b=U4q32/rfGq9w+bSl++Voj3jErOzHopqHFSCG1ZCNHrA8sXi5P0MvRB9cLQeFTzLNlO wy7A1A91Kn/3ZBD9EtSQ7dKkdAIVbQ3VlPScpWJPPib8NE8VvqjD2X+MRIt6/t6gjGQr DC6QlO0VcQnkoZgItRZRAtIL6cMvP3N2YPOGsHMoaQHHEy8HuftwXSRkFszrid32rdkO z7tRS0YevWvzb51xWq56bZuiHu6g4pmr5Any+GjRGaf2omKMKyiwhAxnF0Owe/BfZO8B 1Jy1ojfzHEZ49DNTdaGIByA9E11eO76Y/3GaWeEGSZy5IHjFHiR+z73q+8F7Ft0LBznV VK6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pZLWDFS8RgdNHPorQYwwXOayoTTe55X/Bje9P63wXrs=; b=caJsbZEXRXZs8wkH36TBMX3mfgBKonzsdgTjmdct4flL3fmaCRXpCGIhqw5EezGMcY qGKRDeWh8+fqwB69QfH0sKFgNNAQJyYhSVwfD+RRH2lrJqtY7R9NFtBx7uopvGntgsLQ YA+0TO8QbMxXblmNpa6CXsEuWwR1ol1mf02DzOZccTbsnSnfyzQM5CAY8l1iCYbR3s0a uz4mrIjdpAW/jA9KOWTJR4xvJ8stK/EKjbnvLHaive1XE4PR4YtfaBufO4m6r1gWIsWq 9kDV21HHKKjtt3vhGQxBs4/yu/VrPCY15Xu5wHgCaDSIJghNjOnbyd6IRhO/ziJ1mt3C ga/Q== X-Gm-Message-State: AOAM531BiLnd7HvJ+Ntteei+HmN3Qt4hufKHHTxNkOjFDQSZf1qWHlVP 74xB2qVQ6we+is/pIlcXSR02s2bjP0G9jFrSlLgpTg== X-Received: by 2002:a19:f00f:0:b0:471:b497:8583 with SMTP id p15-20020a19f00f000000b00471b4978583mr14125238lfc.502.1650901941658; Mon, 25 Apr 2022 08:52:21 -0700 (PDT) MIME-Version: 1.0 References: <20220423102421.16869-1-fmdefrancesco@gmail.com> <20220423102421.16869-4-fmdefrancesco@gmail.com> <2583087.X9hSmTKtgW@leap> In-Reply-To: <2583087.X9hSmTKtgW@leap> From: Todd Kjos Date: Mon, 25 Apr 2022 08:52:09 -0700 Message-ID: Subject: Re: [PATCH 3/3] binder: Use kmap_local_page() in binder_alloc_get_page() To: "Fabio M. De Francesco" Cc: Todd Kjos , linux-kernel@vger.kernel.org, Christophe JAILLET , Greg Kroah-Hartman , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Martijn Coenen , Joel Fernandes , Christian Brauner , Hridya Valsaraju , Suren Baghdasaryan , Ira Weiny Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 24, 2022 at 2:40 AM Fabio M. De Francesco wrote: > > On sabato 23 aprile 2022 18:02:48 CEST Christophe JAILLET wrote: > > Hi, > > > > Le 23/04/2022 =C3=A0 12:24, Fabio M. De Francesco a =C3=A9crit : > > > The use of kmap_atomic() is being deprecated in favor of > kmap_local_page() > > > where it is feasible. Each call of kmap_atomic() in the kernel create= s > > > a non-preemptible section and disable pagefaults. This could be a > source > > > of unwanted latency, so it should be only used if it is absolutely > > > required, otherwise kmap_local_page() should be preferred. > > > > > > With kmap_local_page(), the mapping is per thread, CPU local and not > > > globally visible. Furthermore, the mapping can be acquired from any > context > > > (including interrupts). > > > > > > Therefore, use kmap_local_page() / kunmap_local() in place of > > > kmap_atomic() / kunmap_atomic(). > > > > > > Signed-off-by: Fabio M. De Francesco > > > --- > > > drivers/android/binder_alloc.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/android/binder_alloc.c b/drivers/android/ > binder_alloc.c > > > index 0875c463c002..058595cc7ff0 100644 > > > --- a/drivers/android/binder_alloc.c > > > +++ b/drivers/android/binder_alloc.c > > > @@ -1250,17 +1250,17 @@ static int binder_alloc_do_buffer_copy(struct > binder_alloc *alloc, > > > page =3D binder_alloc_get_page(alloc, buffer, > > > buffer_offset, > &pgoff); > > > size =3D min_t(size_t, bytes, PAGE_SIZE - pgoff); > > > - base_ptr =3D kmap_atomic(page); > > > + base_ptr =3D kmap_local_page(page); > > > tmpptr =3D base_ptr + pgoff; > > > if (to_buffer) > > > memcpy(tmpptr, ptr, size); > > > else > > > memcpy(ptr, tmpptr, size); > > > > in the same spirit as patch 1/3, memcpy_to_page() and memcpy_from_page(= ) > > looks good candidate to avoid code duplication. > > Hello Christophe, Todd, > > I had thought to use memcpy_to_page() and memcpy_from_page() (exactly as = I > did in other conversions I have been working on during the latest couple = of > weeks). > > However, I decided to avoid to use them for I should also have deleted th= e > comment which is before "kunmap_local(base_ptr);". > > I don't know how much Maintainers think it is necessary to make readers > notice that "kunmap_local() takes care of flushing the cache []" (exactly > as kunmap_atomic() does). Actually I'd delete that comment that looks > redundant and unnecessary to me, but I cannot know if Todd wants it to > remain there. > > @Todd: Can you please say what you think about this topic? Should I leave > the patch as-is or I should use memcpy_{to,from}_page() and delete that > comment? I'm fine with using memcpy_{to,from}_page() and removing the comment. > > I won't send any v2 unless I have your confirmation. > > Thanks, > > Fabio > > > > > Not checked in details, but looks mostly the same. > > > > Just my 2c. > > > > CJ > > > > > /* > > > - * kunmap_atomic() takes care of flushing the cache > > > + * kunmap_local() takes care of flushing the cache > > > * if this device has VIVT cache arch > > > */ > > > - kunmap_atomic(base_ptr); > > > + kunmap_local(base_ptr); > > > bytes -=3D size; > > > pgoff =3D 0; > > > ptr =3D ptr + size; > > > > > > > >