lkml.org 
[lkml]   [1999]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Measured overhead of timer interrupts
    kuznet@ms2.inr.ac.ru wrote:
    >
    > > I see your point. The problem is that the /proc files are an
    > > exported interface; nettools isn't the only thing that uses
    >
    > I do not know any application using timer values from /proc/net
    > but net-tools, so that all this subject looks shallow.
    >
    > Look at your patch again and try to guess, what apps use these
    > timer values... one, two, three... I bet you did not remeber
    > anything but net-tools and, probably, procps, right?

    you lost :) (think tools that examine socket state and timers
    to make decisions whether to setup/tear down a link. Guess why
    i immediately noticed the broken /proc timers... :^) )


    > > hmm, i'm not sure how to interpret this - it sounds to me
    > > much like:
    > >
    > > We don't care about any apps that use the info exported
    > > through /proc. All applications must be prepared to deal
    > > with numeric values suddenly changing by an order of
    > > magnitude after a kernel reconfiguration/upgrade. We will
    > > do nothing to even try to help them detect this change.
    > >
    > > I hope i misundertood you.
    >
    > No, you understood me correctly. If some variable may jump
    > and application is not ready to it, it is just buggy.

    Where was/is HZ defined as variable (on a given architecture)?
    There are however a lot of places that document/assume a
    constant HZ. Why would an application assume HZ, as presented
    to it, could ever change when HZ was and still is not even
    exported to userspace properly? Just how do you expect
    applications to "be ready" for a numeric value being 2048
    instead of 200 - detect and handle it properly, when you are
    not telling it the unit?


    > If the variable was fixed for ages (as HZ), and then jumped
    > unexpectedly, you have to upgrade.

    if you start changing well known constants, and not even
    provide a way to detect legacy application which are affected
    I'm afraid upgrading applications is not what the solution
    would be...


    > > (1) exporting the HZ value somewhere in /proc, and fixing all
    > > apps to use that for scaling
    >
    > Yes. Only this "all" consists of couple of apps. 8)

    Which you happen to know of. Other than the inhouse custom apps
    in use, there are then also any (commercial or otherwise) closed
    source apps - do you really expect everybody to trace those just
    to make sure they are not depending on the timer values?

    > At least, I set HZ to 1024 on Pentiums and never encountered any problems.

    I got bitten within minutes...


    > > (3) like (2), but making the new i/f generic enough (ie use raw
    > > values, but also export the units and granularity information
    > > (eg a value can be in ms, but only have a resolution of 4ms
    > > so both would be needed)); documenting it, declaring the old
    > > files obsolete, fixing all apps to use the new scheme.
    >
    > It is correct, I see you did look at psched timers. 8)

    Actually, I have no idea what you're talking about :)
    The above scheme is what I would like to have for some of my
    applications, and what I think would be generic enough for
    all possible use, that's all.


    > With one correction: currently existing /proc/ nodes need no fixups.
    > New one should be clean, certainly.

    unfortunately existing /proc files cannot be fixed properly.
    If I'm going to "fix" applications I would rather do it once, using
    _new_ proc nodes, anyway.


    > > '100' >/proc/whatever" suddenly can mean something very different
    >
    > Yes! It is absolutely correct. sysctl variables are measured
    > in seconds, when their value in jiffies is not important.
    >
    > When they are measured in jiffies, they are measured in jiffies
    > and echo 1 means 1 jiffie.

    Things get more complicated when you can have more than one HZ
    value... (something like andi's suggestion (picking the largest
    HZ) might be an acceptable solution)
    [I not sure I like the idea of conditionalizing the startup
    scripts for different HZ :) ]


    > > yes. for development this can be obtained by other means (like
    > > another proc file with raw data / /dev/mem / kernel debugger).
    > > for gathering data from production boxes, masquerading this data
    > > could be a problem.
    >
    > 8) Please, scan linux-kernel.
    >
    > Timer values reported at least by /proc/net are suitable for debugging,
    > only for debugging and for nothing but debugging.

    I _currently_ _use_ them, you may argue that was not their
    purpose, but what do you suggest instead?


    > If you tried to teach someone to fetch timer of stuck TCP socket
    > with gdb to report bug, you would be of different opinion. 8)

    that was just one of the solutions, and why i said there could
    be problems ;)
    new /proc files with raw data would solve the problem.
    if you design them right they could be used instead of the
    old ones (in "upgraded"/new apps) and the whole problem would
    be solved once and for all. There aren't that many proc nodes
    involved...


    > Yes. Though it would be better not to use bizarre HZ values,
    > 1024 is good enough on modern machines and 100 for ancient ones.

    I currently support 100,200,400,800,1024 for ia32 (mostly so
    that the scaling is as lossless as possible).


    How about changing the ipv6 nodes to report the values using
    some, documented, constant unit? I don't believe there are
    many things that depend on these values yet so at least this
    coould be fixed now...

    Couldn't the ((s32)(tcp_time_stamp - tp->ts_recent_stamp) >= PAWS_24DAYS)
    check use a bit scaled down values so it works with HZ>1024 on
    32 bit platforms?

    artur


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

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:2.996 / U:0.372 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site