All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-mm@kvack.org, Heiko Carstens <heiko.carstens@de.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v1 1/2] mm/memblock: expose only miminal interface to add/walk physmem
Date: Tue, 30 Jun 2020 18:58:41 +0200	[thread overview]
Message-ID: <bbd86b6e-e344-514f-7a10-e1078cb60e99@redhat.com> (raw)
In-Reply-To: <20200630162929.GC2500444@linux.ibm.com>

>>  extern struct memblock memblock;
>> @@ -114,6 +110,19 @@ int memblock_remove(phys_addr_t base, phys_addr_t size);
>>  int memblock_free(phys_addr_t base, phys_addr_t size);
>>  int memblock_reserve(phys_addr_t base, phys_addr_t size);
>>  #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP
>> +/**
>> + * for_each_physmem_range - iterate through physmem areas not included in type.
>> + * @i: u64 used as loop variable
>> + * @type: ptr to memblock_type which excludes from the iteration, can be %NULL
>> + * @p_start: ptr to phys_addr_t for start address of the range, can be %NULL
>> + * @p_end: ptr to phys_addr_t for end address of the range, can be %NULL
>> + */
>> +#define for_each_physmem_range(i, type, p_start, p_end)			\
>> +	for (i = 0, __next_physmem_range(&i, type, p_start, p_end);	\
>> +	     i != (u64)ULLONG_MAX;					\
>> +	     __next_physmem_range(&i, type, p_start, p_end))
>> +void __next_physmem_range(u64 *idx, struct memblock_type *type,
>> +			  phys_addr_t *out_start, phys_addr_t *out_end);
> 
> __next_physmem_range() is not really necessary, the
> for_each_physmem_range() macro can use __next_mem_range() directly, but
> I suspect it won't look nice :)
> 
> Can you please make __next_physmem_range() static inline if we are to
> keep it?

The thing is, then I have to expose "physmem" to something outside
memblock.c. That's what I wanted to avoid here. (instead, have a minimal
interface that is sufficient enough for this special case of physmem -
add memory during boot, walk memory after boot. Performance is not an
issue).

[...]

>>   * Each region is represented by :c:type:`struct memblock_region` that
>>   * defines the region extents, its attributes and NUMA node id on NUMA
>>   * systems. Every memory type is described by the :c:type:`struct
>>   * memblock_type` which contains an array of memory regions along with
>> - * the allocator metadata. The memory types are nicely wrapped with
>> - * :c:type:`struct memblock`. This structure is statically initialzed
>> - * at build time. The region arrays for the "memory" and "reserved"
>> - * types are initially sized to %INIT_MEMBLOCK_REGIONS and for the
>> - * "physmap" type to %INIT_PHYSMEM_REGIONS.
>> + * the allocator metadata. The memory types (except "physmem") are nicely
>> + * wrapped with :c:type:`struct memblock`. This structure is statically
>> + * initialized at build time. The region arrays for the "memory" and
>> + * "reserved" types are initially sized to %INIT_MEMBLOCK_REGIONS.
> 
> I'd prefer
> 
> 	... The "memory" and "reserved" types are nicely wrapped 
> 	with :c:type:`struct memblock`. This structure is statically
>         initialized at build time. 
> 
> And while on this we can update the "reserved" size to match the code:
> 
> 	The region arrays are initilily sized to %INIT_MEMBLOCK_REGIONS
>  	for "memory" and %INIT_MEMBLOCK_RESERVED_REGIONS for "reserved".

Ack to both!

-- 
Thanks,

David / dhildenb

  reply	other threads:[~2020-06-30 16:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30  8:17 [PATCH v1 0/2] s390/mm: don't set ARCH_KEEP_MEMBLOCK David Hildenbrand
2020-06-30  8:17 ` [PATCH v1 1/2] mm/memblock: expose only miminal interface to add/walk physmem David Hildenbrand
2020-06-30  8:19   ` David Hildenbrand
2020-06-30 16:29   ` Mike Rapoport
2020-06-30 16:58     ` David Hildenbrand [this message]
2020-06-30 17:11       ` David Hildenbrand
2020-06-30  8:17 ` [PATCH v1 2/2] s390/mm: don't set ARCH_KEEP_MEMBLOCK David Hildenbrand

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=bbd86b6e-e344-514f-7a10-e1078cb60e99@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=rppt@linux.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.