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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 47993C433E0 for ; Thu, 4 Feb 2021 15:23:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BAEDB64E41 for ; Thu, 4 Feb 2021 15:23:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BAEDB64E41 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=soleen.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2A4CB6B006C; Thu, 4 Feb 2021 10:23:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 252906B0070; Thu, 4 Feb 2021 10:23:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11C136B0071; Thu, 4 Feb 2021 10:23:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E892E6B006C for ; Thu, 4 Feb 2021 10:23:42 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A97431EF1 for ; Thu, 4 Feb 2021 15:23:42 +0000 (UTC) X-FDA: 77780955084.16.ducks17_5212b48275dd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 8DDE4100E6912 for ; Thu, 4 Feb 2021 15:23:41 +0000 (UTC) X-HE-Tag: ducks17_5212b48275dd X-Filterd-Recvd-Size: 6900 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Thu, 4 Feb 2021 15:23:40 +0000 (UTC) Received: by mail-ed1-f44.google.com with SMTP id z22so4566130edb.9 for ; Thu, 04 Feb 2021 07:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zEhxV9P2S1PvM6vEfxJN1WEpwz1WJWS0uG/glB9T2Jg=; b=f8TCB65kOI/5YD4eYt2VzD1Wu2rvsxhlN8adiVviJVV4DA3Wl7/uHJ9CE575xk9utB e6qh2Xgr7I53+Pacq4xLIECgNw/4wlm0i7bomuGKvWRbuKpt9myaXRmoMDNJmJrEiYC/ aSqgHfRGTgJ5ZdDcw3kflrqi+7tysmdWl9XC6RqMv9FTm4OdAGl5aMqf4cly/vuLcLgC 3nS+4V7vHsEWK0jeD1ISELKCGy+JAcZSrTPgupHHL1No+JZkz2nQueGJevCira8IouP2 KMxixMQIcqAwBkUg8LVD65bZtqvdWLcfPW5ipl9UPvJrc25Ux1fuacSJxpHfjpDD1+5o MTEg== 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; bh=zEhxV9P2S1PvM6vEfxJN1WEpwz1WJWS0uG/glB9T2Jg=; b=tGFc/CTgdZakXcuDobhYfqP4+aTeLfanR87aZDdqwNsh9JKxLL4NUwfvDE5XiX6q9s 3j4jZC+DKsdFxbTVn83OhuyibXbPD9AHW0R/+JOsrHIuXzai/42fh1R367C1Qi6XgzCY b/zvQyVDeQ2AuBcwEsai57EBKyerFPSuM40IVkDOLIlhifcGgG0bxlXzZ/lv0qJCnfe4 JpkW8Rx+cG9VMu1le8JsbR9eQIBZnrUtdfnuB4I4WBBN/JlGwyxz/bUvvPd43mi3J961 KcCeWn46nwQ5sp4gT2YpkfGF4thn1G3QDsWSSkotnVaiKHAUUn8jZOfhm5jakizi8J/X QKyg== X-Gm-Message-State: AOAM530Z6UtEzLwQg+rHuYgUz09h7HxzG74c+C4AEPQ+XAusaew5Bc3R a9s4DMd+g/kprXHgH0bULdGcyvK0oalKFGlVPZT0VQ== X-Google-Smtp-Source: ABdhPJyUmQPsLbf5BWKf5fk9Y5JfnVPXqyhY/9QKj8WdKnBuqLGTetkIY8rtIz18JSsEieS+eamybo+g83gzcFyKHi0= X-Received: by 2002:aa7:cd0a:: with SMTP id b10mr8283776edw.153.1612452219646; Thu, 04 Feb 2021 07:23:39 -0800 (PST) MIME-Version: 1.0 References: <20210127172706.617195-1-pasha.tatashin@soleen.com> <871rdwocwh.fsf@x220.int.ebiederm.org> In-Reply-To: <871rdwocwh.fsf@x220.int.ebiederm.org> From: Pavel Tatashin Date: Thu, 4 Feb 2021 10:23:03 -0500 Message-ID: Subject: Re: [PATCH v11 0/6] arm64: MMU enabled kexec relocation To: "Eric W. Biederman" Cc: James Morse , James Morris , Sasha Levin , kexec mailing list , LKML , Jonathan Corbet , Catalin Marinas , Will Deacon , Linux ARM , Marc Zyngier , Vladimir Murzin , Matthias Brugger , linux-mm , Mark Rutland , steve.capper@arm.com, rfontana@redhat.com, Thomas Gleixner , Selin Dag , Tyler Hicks Content-Type: text/plain; charset="UTF-8" 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: > > I understand that having an extra set of page tables could potentially > > waste memory, especially if VAs are sparse, but in this case we use > > page tables exclusively for contiguous VA space (copy [src, src + > > size]). Therefore, the extra memory usage is tiny. The ratio for > > kernels with 4K page_size is (size of relocated memory) / 512. A > > normal initrd + kernel is usually under 64M, an extra space which > > means ~128K for the page table. Even with a huge relocation, where > > initrd is ~512M the extra memory usage in the worst case is just ~1M. > > I really doubt we will have any problem from users because of such > > small overhead in comparison to the total kexec-load size. Hi Eric, > > Foolish question. Thank you for your e-mail, you gave some interesting insights. > > Does arm64 have something like 2M pages that it can use for the > linear map? Yes, with 4K pages arm64 as well has 2M pages, but arm64 also has a choice of 16K and 64K and second level pages are bigger there. > On x86_64 we always generate page tables, because they are necessary to > be in 64bit mode. As I recall on x86_64 we always use 2M pages which > means for each 4K of page tables we map 1GiB of memory. Which is very > tiny. > > If you do as well as x86_64 for arm64 I suspect that will be good enough > for people to not claim regression. > > Would a variation on the x86_64 implementation that allocates page > tables work for arm64? ... > > As long as the page table provided is a linear mapping of physical > memory (aka it looks like paging is disabled). The the code that > relocates memory should be pretty much the same. > > My experience with other architectures suggests only a couple of > instructions need to be different to deal with a MMU being enabled. I think what you are proposing is similar to what James proposed. Yes, for a linear map relocation should be pretty much the same as we do relocation as with MMU disabled. Linear map still uses memory, because page tables must be outside of destination addresses of segments of the next kernel. Therefore, we must allocate a page table for the linear map. It might be a little smaller, but in reality the difference is small with 4K pages, and insignificant with 64K pages. The benefit of my approach is that the assembly copy loop is simpler, and allows hardware prefetching to work. The regular relocation loop works like this: for (entry = head; !(entry & IND_DONE); entry = *ptr++) { addr = __va(entry & PAGE_MASK); switch (entry & IND_FLAGS) { case IND_DESTINATION: dest = addr; break; case IND_INDIRECTION: ptr = addr; break; case IND_SOURCE: copy_page(dest, addr); dest += PAGE_SIZE; } } The entry for the next relocation page has to be always fetched, and therefore prefetching cannot help with the actual loop. In comparison, the loop that I am proposing is like this: for (addr = head; addr < end; addr += PAGE_SIZE, dst += PAGE_SIZE) copy_page(dest, addr); Here is assembly code for my loop: 1: copy_page x1, x2, x3, x4, x5, x6, x7, x8, x9, x10 sub x11, x11, #PAGE_SIZE cbnz x11, 1b That said, if James and you agree that linear map is the way to go forward, I am OK with that as well, as it is still much better than having no caching at all. Thank you, Pasha