linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Matthew Wilcox <willy@infradead.org>,
	Wei Yang <richard.weiyang@gmail.com>
Cc: Baoquan He <bhe@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	mhocko@suse.com, akpm@linux-foundation.org, david@redhat.com
Subject: Re: [PATCH v2] mm/sparse.c: Use kvmalloc_node/kvfree to alloc/free memmap for the classic sparse
Date: Fri, 13 Mar 2020 15:46:28 +0100	[thread overview]
Message-ID: <c5b8328f-a46f-6f5b-2ef0-e1d8a375fa8e@suse.cz> (raw)
In-Reply-To: <20200313000041.GM22433@bombadil.infradead.org>

On 3/13/20 1:00 AM, Matthew Wilcox wrote:
> On Thu, Mar 12, 2020 at 10:50:55PM +0000, Wei Yang wrote:
>> On Thu, Mar 12, 2020 at 07:25:35AM -0700, Matthew Wilcox wrote:
>> >Yes, I thought about that.  I decided it wasn't a problem, as long as
>> >the struct page remains aligned, and we now have a guarantee that allocations
>> >above 512 bytes in size are aligned.  With a 64 byte struct page, as long
>> 
>> Where is this 512 bytes condition comes from?
> 
> Filesystems need to do I/Os from kmalloc addresses and those I/Os need to
> be 512 byte aligned.

To clarify, the guarantee exist for every power of two size. The I/O usecase was
part of the motivation for the guarantee, but there is not 512 byte limit. But
that means there is also no guarantee for a non-power-of-two size above (or
below) 512 bytes. Currently this only matters for sizes that fall into the 96
byte or 192 byte caches. With SLOB it can be any size.

So what I'm saying the allocations should make sure they are power of two and
then they will be aligned. The page size of 64bytes depends on some debugging
options being disabled, right?

>> >as we're allocating at least 8 pages, we know it'll be naturally aligned.
>> >
>> >Your calculation doesn't take into account the size of struct page.
>> >128M / 64k is indeed 2k, but you forgot to multiply by 64, which takes
>> >us to 128kB.
>> 
>> You are right. While would there be other combination? Or in the future?
>> 
>> For example, there are definitions of
>> 
>> #define SECTION_SIZE_BITS       26
>> #define SECTION_SIZE_BITS       24
>> 
>> Are we sure it won't break some thing?
> 
> As I said, once it's at least 512 bytes, it'll be 512 byte aligned.  And I
> can't see us having sections smaller than 8 pages, can you?
> 



  parent reply	other threads:[~2020-03-13 14:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-12 13:08 Baoquan He
2020-03-12 13:34 ` Matthew Wilcox
2020-03-12 13:54   ` Baoquan He
2020-03-12 14:18   ` Wei Yang
2020-03-12 14:25     ` Matthew Wilcox
2020-03-12 22:50       ` Wei Yang
2020-03-13  0:00         ` Matthew Wilcox
2020-03-13 14:35           ` David Hildenbrand
2020-03-13 14:46           ` Vlastimil Babka [this message]
2020-03-13 14:57     ` Michal Hocko
2020-03-13 21:54       ` Wei Yang
2020-03-12 14:17 ` [PATCH v3] " Baoquan He
2020-03-13 14:56   ` Michal Hocko
2020-03-14  0:53     ` Baoquan He
2020-03-14 12:56       ` Michal Hocko
2020-03-15 13:01         ` Baoquan He
2020-03-14  1:12     ` Baoquan He
2020-03-13 15:04   ` David Hildenbrand
2020-03-16  7:14     ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c5b8328f-a46f-6f5b-2ef0-e1d8a375fa8e@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=richard.weiyang@gmail.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox