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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95E62C6379F for ; Mon, 13 Feb 2023 15:16:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0DD376B0071; Mon, 13 Feb 2023 10:16:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 08F146B0072; Mon, 13 Feb 2023 10:16:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E97036B0073; Mon, 13 Feb 2023 10:16:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D7D566B0071 for ; Mon, 13 Feb 2023 10:16:13 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8043BC084D for ; Mon, 13 Feb 2023 15:16:13 +0000 (UTC) X-FDA: 80462619426.12.005BF76 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id 21622C001E for ; Mon, 13 Feb 2023 15:16:10 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=NUGzBDPf; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676301371; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=V8mVIgS1WiaMF9eNsPnfVifYmMvN5+MFQdtCI1uWXnc=; b=U2KtsWIa2gYv99AnS7Jc7e/K3msGmGgR/CtZWIMNfDbtPY2U00G/7xQClAbTz++KPyBkkf cKcIrt9+EO5W2R8BOQHUSuceXsdy086zV53/UN0eMuotL3XvmiJUO3U7otK0O8MCf5AmL/ IjPIUquOIzAJxVibHTaozHDl2ubLpIE= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=NUGzBDPf; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676301371; a=rsa-sha256; cv=none; b=OL2p1mVcDh5JqgsyY8Rc9HKvPotFmc9p1iO+AVchOunaQfqb3Zw1+bTDb8+OicSr2xbBgJ IXwor7yfJaZ98XvBjNpmOYcktZ6MbN581GT16+ZMybuxZJI36Q2rLMoBTumTMNZTBw8ZBN i8pbVcpiv0drljpfLAskbBRHD/dvFis= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=V8mVIgS1WiaMF9eNsPnfVifYmMvN5+MFQdtCI1uWXnc=; b=NUGzBDPfDygATgByXS5fWC9PfF 8AY3wPQBs21++97GyKYnNUId6Lc3j+9jqddifXMJxz0e4rl87hWhTu4QO9sYTn+biQYtsA1v1Pu69 wA4HDD4N3M/FmbJHdf7VVZTznMQHkOxJlIay0SkR/PPVmj20dfAsJsjmQ5AjNoJ+PByJ/V8CmIfh4 eb+8KAr+oLjtXESTLZ+AzIE91Nk6EA20Ogjr7OW4SisEh9JEAWarJ0qT4kKQxHWCwENMUrEl99j3v fWhYM5Y7HweXoG3rll00ZXES2PMUYvOpLWcuHwcROycpbDYyFmzNL+Osexk2MPTDcczuDoJY5Pt2u bsWudaFg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pRaYr-005sKE-8N; Mon, 13 Feb 2023 15:16:09 +0000 Date: Mon, 13 Feb 2023 15:16:09 +0000 From: Matthew Wilcox To: "Yin, Fengwei" Cc: "linux-mm@kvack.org" , "linux-arch@vger.kernel.org" Subject: Re: [PATCH 6/7] arc: Implement the new page table range API Message-ID: References: <20230211033948.891959-1-willy@infradead.org> <20230211033948.891959-7-willy@infradead.org> <8a84172a5007b568392b2040e889780da198e20f.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8a84172a5007b568392b2040e889780da198e20f.camel@intel.com> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 21622C001E X-Stat-Signature: b1hgkc6aakp93pmmghx79hxqpjoynt15 X-HE-Tag: 1676301370-976801 X-HE-Meta: U2FsdGVkX18CBKNLJ2IUT6h2NzBfbTjcjERdgmZlA88dZpo7Q/Yae5tU6f0PF109KIzBOFLW/lqbOi5y7kX9Pstr5EcOTykedahvn1JpDb+gK15ib7Y23Ab2jbjqFGWNV7/RzNtbDclUD02UOfKyG2i9KQYa0HBnpJHRR+rd1AdvFwzpE/Fc7tT1eqWPopjCc8bJPztr24QCwQZKo9Al76KBZv+jQbu0kD8Lj+Y6X6hTWucwqm8daijep3W+68b9KxpuP9cEYMqp3mqZu15bcqm09T7q5OKrbuQNDllF4326aT2m26VGlQs8Z3f9gP6TnV4c9ah7eXYMz6faCv+SXfPybPqN2NVo9Amcj+OJVH1L0t3ZYY69DEO8kkw5QjcznhqHgv44TtlFXEFR8O4xlJ2mex1vxUlfKFvs0bdTY2oHndPkkjXXvnUpoNZL9+agYB5O0dUuiHbuZnN6ltyU+f9LxHiIOnxQMiqhPFd2jb+l+3N5hSK+tDbbV+xRivMwsepmIjt1Obt489XoPA8fp4vLVS1vLqrrfv5/AW+plE3H9bbpbtw7sKQ9gIgrjTpff3zYTW0DgOmuODK+182N0gzKdVq1IgsIEKVQe3mhEKvJuJrrL24qe4lGRK/s6Zayofj7qb7iYIgmHY51rlUdS2N0sDJDg6W9LpxSOh8ShH0r5IxeVXlj/KCrprSlk5F4YBa3FqjkvUldWDbJXN+p439TeUoeRQiD4uMuNLLvZMUJ78A4DBda3H7rFG1NexbYvxcbrQ6ENEe/D5bjMpI+bW+oJ0qOADbH3diIsB2FImyJGKUNOFLiN6EQ1Pi9xApZJOvAskPHEdlxN6nTzyUPrLrGy4XVliln4zkvmUX+BW5Fnhth+ItZ3LZnrWJviTfaOuu8oLhFh3PjnTVDkiZqc2Z0yod4devmzjLLxt9qPdl9eMeZ+WtBKHRw/o6TAVI80y4vg2Yiw7J0bq+VHSf 8CcD+UJJ 5/sUpT3qf6+NT1DsafAlQh/GSH7FXSbhtR1V4h/I+m28weX2zLany/5CbMqw6mB78FkqtVJEODkkhZwC7h+Qhjpn7ReJue2TacqJunu6YnuTxySnoOgDdhuDj7jmQlRqt+zg2BMvaUt8QcsTaiFnI5pZXFNh6Mkggtp30jBQnFjNS9ueWspWbqgjKWhL3SnF7rSXw 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 Mon, Feb 13, 2023 at 03:09:37AM +0000, Yin, Fengwei wrote: > > +++ b/arch/arc/include/asm/cacheflush.h > > @@ -25,17 +25,20 @@ > >   * in update_mmu_cache() > >   */ > >  #define flush_icache_page(vma, page) > > +#define flush_icache_pages(vma, page, nr) > Maybe just remove these two definitions because general > implementation is just no-op? Then arc would have to include asm-generic/cacheflush.h and I don't particularly want to debug any issues that might cause. This is easier. Long term, asm-generic/cacheflush.h's contents should be moved into linux/cacheflush.h, but I've lacked the time to do that work. To answer your question from the other email, the documentation says: ``void flush_icache_page(struct vm_area_struct *vma, struct page *page)`` All the functionality of flush_icache_page can be implemented in flush_dcache_page and update_mmu_cache_range. In the future, the hope is to remove this interface completely. I'm not planning on doing that to an architecture that I'm not set up to test ... > > +void flush_dcache_page(struct page *page) > > +{ > > +       return flush_dcache_folio(page_folio(page)); > > +} > I am wondering whether we should add flush_dcache_folio_range() > because it's possible just part of folio needs be flush. Thanks. We could. I think it's up to the maintainers of architectures that need their caches flushing to let us know what would be good for them. Since I primarily work on x86, I have no personal desire to do this ;-) One of the things that I've always found a little weird about flush_dcache_page() (and now flush_dcache_folio()) is that it's used both for flushing userspace writes (eg in filemap_read()) and for flushing kernel writes (eg in __iomap_write_end()). Probably it was designed for an architecture that flushes by physical address rather than by virtual. Anyway, if we do have a flush_dcache_folio_kernel(), I'd like it to take byte offsets. That would work well for __iomap_write_end(); it could be: flush_dcache_folio_kernel(folio, offset_in_folio(folio, pos), len); But I'm not volunteering to do this work.