linux-kernel - Re: [Patch1/4]: fake numa for x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 28 Nov 2006 14:20:53 -0800
From:	Rohit Seth <rohitseth@...gle.com>
To:	Mel Gorman <mel@....ul.ie>
Cc:	Andi Kleen <ak@...e.de>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	David Rientjes <rientjes@...washington.edu>,
	Paul Menage <menage@...gle.com>, Andrew Morton <akpm@...l.org>
Subject: Re: [Patch1/4]: fake numa for x86_64 patch

On Tue, 2006-11-28 at 21:34 +0000, Mel Gorman wrote:
> On Tue, 28 Nov 2006, Rohit Seth wrote:
> 
> > On Tue, 2006-11-28 at 13:24 +0000, Mel Gorman wrote:
> >> On Mon, 27 Nov 2006, Rohit Seth wrote:
> >>
> >>> Hi Mel,
> >>>
> >>> On Mon, 2006-11-27 at 13:18 +0000, Mel Gorman wrote:
> >>>> On Wed, 22 Nov 2006, Rohit Seth wrote:
> >>>>
> >>>>> This patch provides a IO hole size in a given address range.
> >>>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> This patch reintroduces a function that doubles up what
> >>>> absent_pages_in_range(start_pfn, end_pfn). I recognise you do this because
> >>>> you are interested in hole sizes before add_active_range() is called.
> >>>
> >>> Right.
> >>>
> >>>>
> >>>> However, what is not clear is why these patches are so specific to x86_64.
> >>>>
> >>>
> >>> Specifically in the fake numa case, we want to make sure that we don't
> >>> carve fake nodes that only have IO holes in it.  Unlike the real NUMA
> >>> case, here we don't have SRAT etc. to know the memory layout beforehand.
> >>>
> >>>
> >>>> It looks possible to do the work of functions like split_nodes_equal() in
> >>>> an architecture-independent manner using early_node_map rather than
> >>>> dealing with the arch-specific nodes array. That would open the
> >>>> possibility of providing fake nodes on more than one architecture in the
> >>>> future.
> >>>
> >>> The functions like splti_nodes_equal etc. can be abstracted out to arch
> >>> independent part.  I think the only API it needs from arch dependent
> >>> part is to find out how much real RAM is present in range without have
> >>> to first do add_active_range.
> >>>
> >>
> >> That is a problem because the ranges must be registered with
> >> add_active_range() to work out how much real RAM is present.
> >>
> >
> > Right.  And that is why I need e820_hole_size functionality. BTW, what
> > is the concern in having that function?
> >
> 
> Because it provides almost identical functionality to another function. If 
> that can be avoided, it's preferable.
> 

There are subtle difference in the way two function can be used.  They
are operating in two different environments. absent_pages work when
memory layout is already registered.  The e820_hole_size is the (low
level arch dependent) function that will be used to find out how the
memory lay out is going to be set for the cases when kernel has to
itself decide about the layout.

-rohit

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/