On 18.03.21 13:03, Oscar Salvador wrote:
On Thu, Mar 18, 2021 at 12:24:16PM +0100, David Hildenbrand wrote:
I don't follow. 2MB == 2MB. And if there would be difference then we would
be in the problem I brought up: vmemmap code allocating too much via the
altmap, which can be very bad because mi
On Thu, Mar 18, 2021 at 12:24:16PM +0100, David Hildenbrand wrote:
> I don't follow. 2MB == 2MB. And if there would be difference then we would
> be in the problem I brought up: vmemmap code allocating too much via the
> altmap, which can be very bad because might be populating more vmemmap than
>
On 18.03.21 11:38, Oscar Salvador wrote:
On Thu, Mar 18, 2021 at 09:27:48AM +0100, Oscar Salvador wrote:
If we check for
IS_ALIGNED(nr_vmemmap_pages, PMD_SIZE), please add a proper TODO comment
that this is most probably the wrong place to take care of this.
Sure, I will stuff the check in th
On Thu, Mar 18, 2021 at 09:27:48AM +0100, Oscar Salvador wrote:
> > If we check for
> >
> > IS_ALIGNED(nr_vmemmap_pages, PMD_SIZE), please add a proper TODO comment
> > that this is most probably the wrong place to take care of this.
>
> Sure, I will stuff the check in there and place a big TODO
On Wed, Mar 17, 2021 at 03:35:41PM +0100, David Hildenbrand wrote:
> Just assume you have two ranges
>
> [ ZONE_DEVICE 0 ][ ZONE_DEVICE 1]
>
> If the vmemmap of ZONE_DEVICE 1 could be taken from the altmap of
> ZONE_DEVICE 0, we could be in trouble, as both parts can be
> removed/repurposed indep
On 17.03.21 15:08, Oscar Salvador wrote:
On Tue, Mar 16, 2021 at 06:45:17PM +0100, David Hildenbrand wrote:
I find that cross reference to vmemmap code a little hard to digest.
I would have assume that we don't have to care about PMDs in this
code here at all. The vmemmap population code should
On Tue, Mar 16, 2021 at 06:45:17PM +0100, David Hildenbrand wrote:
> > I find that cross reference to vmemmap code a little hard to digest.
> > I would have assume that we don't have to care about PMDs in this
> > code here at all. The vmemmap population code should handle that.
> >
> > I think I
On 16.03.21 17:46, David Hildenbrand wrote:
On 15.03.21 11:22, Oscar Salvador wrote:
On Thu, Mar 11, 2021 at 08:06:53PM +0100, David Hildenbrand wrote:
This looks essentially good to me, except some parts in
mhp_supports_memmap_on_memory()
+bool mhp_supports_memmap_on_memory(unsigned long siz
On 15.03.21 11:22, Oscar Salvador wrote:
On Thu, Mar 11, 2021 at 08:06:53PM +0100, David Hildenbrand wrote:
This looks essentially good to me, except some parts in
mhp_supports_memmap_on_memory()
+bool mhp_supports_memmap_on_memory(unsigned long size)
+{
+ unsigned long pageblock_size =
On Thu, Mar 11, 2021 at 08:06:53PM +0100, David Hildenbrand wrote:
> This looks essentially good to me, except some parts in
> mhp_supports_memmap_on_memory()
>
> > +bool mhp_supports_memmap_on_memory(unsigned long size)
> > +{
> > + unsigned long pageblock_size = PFN_PHYS(pageblock_nr_pages);
>
This looks essentially good to me, except some parts in
mhp_supports_memmap_on_memory()
+bool mhp_supports_memmap_on_memory(unsigned long size)
+{
+ unsigned long pageblock_size = PFN_PHYS(pageblock_nr_pages);
+ unsigned long remaining_mem = size - PMD_SIZE;
This looks weird. I
Physical memory hotadd has to allocate a memmap (struct page array) for
the newly added memory section. Currently, alloc_pages_node() is used
for those allocations.
This has some disadvantages:
a) an existing memory is consumed for that purpose
(eg: ~2MB per 128MB memory section on x86_64)
b
12 matches
Mail list logo
