lkml.org 
[lkml]   [2007]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 6/6] automatic tuning applied to some kernel components
    Andrew Morton wrote:
    >>On Tue, 16 Jan 2007 07:15:22 +0100 Nadia.Derbey@bull.net wrote:
    >>The following kernel components register a tunable structure and call the
    >>auto-tuning routine:
    >> . file system
    >> . shared memory (per namespace)
    >> . semaphore (per namespace)
    >> . message queues (per namespace)
    >
    >
    > This is the part of the patch series which really matters, and I just don't
    > understand it :(
    >
    > Why do we want to autotune these things? What problem is this patch series
    > solving? Please describe this part of the work much, much more completely,
    > so we can understand the need to add such a large amount of code to the
    > kernel.

    1) why these tunables?
    The ipc tunables have been selected as "guinea-pig" tunables for the AKT
    framework because they are likely to be often used in data bases. This
    applies to file-max too.
    Now, if the framework itself is accepted, the set of impacted tunables
    can easily be enhanced.

    2) why autotuning:
    There are at least 3 cases where it can be useful
    . for workloads that are known to need a big amount of a given resource
    type (say shared memories), but we don't know what the maximum amount
    needed will be
    . to solve the case of multiple applications running on a single system,
    and that need the same tunable to be adjusted to feet their needs
    . to make a system correctly react to eventual peak loads for a given
    resource usage, i.e. make it tune up *and down* as needed.

    In all these cases, the akt framework will enable the kernel to adapt to
    increasing / decreasing resource consumption:
    1) avoid allocating "a priori" a big amount of memory that will be used
    only in extreme cases. This is the effect of doing an "echo <huge_value>
    > /proc/sys/kernel/shmmni"
    2) the system will come back to the default values as soon as the peak
    load is over.

    >
    > It seems strange that the whole feature is Kconfigurable. Please also
    > explain the thinking behind that.

    We wanted to make it configurable because it adds some overhead in terms of
    1) generated kernel size
    2) instructions added to the resource creation / removal code paths even
    if auto-tuning is not activated for th corresponding tunable ->
    performance impact.

    >
    > I suspect the patches would be much simpler if you simply required that all
    > these new tunables be of type `long'. About seven eighths of the code
    > would go away. As would most of those eye-popping macros.
    >

    Yes, agree with you: the idea here was to make the framework more
    generic. But I can change that.

    Regards,
    Nadia




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

    \
     
     \ /
      Last update: 2007-01-23 16:23    [W:0.065 / U:1.088 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site