On (23/07/08 16:33), Andy Whitcroft didst pronounce: > This is a further revision of the basic hugectl support incorporating > further feedback, and a number of other cleanups which came out of the > work to address them. The first three patches are effectivly further > cleanups prior to the meat. > > Needing resolution: > > 1) are we going to offer --read-only/--read-write in addition to the segment > oriented options, and
I think you shouldn't because it exposes a low-level feature of the library. If needs be, it can be worked around by setting environment manually and a bug report to fix whatever hugectl did wrong. > 2) is PRELOAD actually always safe if so we can just enable it. There > was confusion about whether the linking order would be broken by it. > I don't know. > Changelog: > > V3: > - abstract out the verbosity levels > - cleanup and abstract long option values > - always indicate environmental variables as they are set > - library path defaults to set, and may be suppressed > - adds --explain to expose configuration > > V2: > - incorporate community feedback > > ==== > > I have been looking at adding basic functionality to hugectl. Following > on from my cleanup series this patch set adds basic remap functionality > to hugectl. The short version of the story is that it adds options to > request backing of the text, data, bss, and heap as first class options > and simplifies preload handling, library path specification, and exposes > configuration on request. > > The main driver for hugectl is to simplify the use of hugepages as > exported through the libhugetlbfs library. Specifically we should be > trying to do what the user means where possible. This patch set brings > basic support for requesting remap and/or backing of the various elements > program elements supported by libhugetlbfs. This includes the request > of remap of the various program segments, as well as requesting the heap > (malloc space) be backed. Where appropriate it tries to configure preload > of the library. > > When considering the current configuration the clearest anomoly seems to be > the difference in handling of normal program segments and malloc. From a > user point of view hugepages are something which I use for something, > to back something. Backing my text with hugepages or my malloc space > with hugepages are the same thing. That is I have a bunch of things, > text, data, bss, malloc all of which I may wish or not wish to back > with hugepages. The underlying implementation differences are hidden by > exposing each as its own option, all at the same level. > > hugectl --text > hugectl --data --bss > hugectl --heap > hugectl --stack (for illustrative purposes only) > hugectl --disable > > Note that while each thing is separately specified, in reality only certain > combinations are valid. Where the user specifies a bad combination it > is "widened" to a valid combination which includes their request and a > warning is emitted. This helps to get the user going and is part of the > DWIM approach. > > Preloading is a little tricky as it is only useful where the binary > is not-prelinked and only there is we are only asking for the heap to > be backed. But in that combination we can always preload safely which should > remove the need to every conciously request it. In case it is a problem > we allow it to be suppressed via --no-preload. > > Finally it is helpful to be able to see the options in use for any > particular combination of arguments, expose this via --explain. > > This stack consists of 9 patches: > > hugectl: convert exit status to POSIX standard codes -- fixes up the exit > codes to use the POSIX standard EXIT_FAILURE et al, > > debug: expose default and maximum verbosity level -- which exposes the > current default and maximum verbosity levels, > > hugectl: bring the main execvp error under the standard error reporting -- > use the ERROR macros to report execvp failures, > > hugectl: honour the hugetlb verbosity/debug flags -- reads the standard > libhugetlbfs verbosity and debug control flags and supplies compatible > error and warning routines, > > hugectl: add remap support via --text, --data, --bss, and --disable -- > which adds basic remap support via separated options, > > hugectl: add backing of the heap via --heap -- which adds heap remapping > via --heap, > > hugectl: add support for preload -- where preload is appropriate request > preloading of the library, > > hugectl: add support for requesting which library to use -- providing > an override for the normal library path allowing clean execution in > non-standard installs, and > > hugectl: explain the hugetlb configuration selected via --explain -- > which allow exposure of the variable settings for a specific command line. > > Note that the first of these patches does duplicate some functionality > from the main library and that will be sorted out as a separate series. > > Thanks for Nish, Adam, Mel, David and Andrew for feedback during this > process. > > Comments? > > -apw > > Andy Whitcroft (9): > debug: expose default and maximum verbosity level > hugectl: convert exit status to POSIX standard codes > hugectl: bring the main execvp error under the standard error > reporting > hugectl: honour the hugetlb verbosity/debug flags > hugectl: add remap support via --text, --data, --bss, and --disable > hugectl: add backing of the heap via --heap > hugectl: add support for preload > hugectl: add support for requesting which library to use > hugectl: explain the hugetlb configuration selected via --explain > > Makefile | 9 ++- > debug.c | 2 +- > hugectl.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++- > libhugetlbfs_debug.h | 3 + > 4 files changed, 224 insertions(+), 7 deletions(-) > -- 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 Libhugetlbfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
