On (30/07/08 09:17), Adam Litke didst pronounce:
> On Tue, 2008-07-29 at 15:44 -0700, Nishanth Aravamudan wrote:
> > On 26.07.2008 [14:30:40 +0100], Andy Whitcroft wrote:
> > > Add control over remap via the --text, --data, --bss, and --disable
> > > options.  The first three request mapping of those segments, the last
> > > disables all remap.  Where the combinations requested cannot be exactly
> > > handled then the request is "widened" to get that segment remapped,
> > > for example if you request --data or --bss in isolation then both are
> > > remapped and a warning emitted.
> > 
> > What about force-remap, which just tries to map whatever segments might
> > already be big enough (even partially on x86/x86_64)?
> 
> Do we consider forced remapping a first-class feature?  I was under the
> impression that it is mostly useful for doing sniff testing but isn't
> really recommended for production use.  If this is true, then I'd say we
> should leave it as an environment-only option (not in hugectl) for the
> time being.
> 

Whether it should be in hugectl or not is beyond the scope of this
patchset IMO. This patchset is about getting hugectl into a useful shape.
The patchset as it stands has plenty of useful functionality with or without
force-remap. So, how about we finish this first and worry about what else
should be in there later?

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel

Reply via email to