On Tue, 27 Mar 2001, Michel Wilson wrote:
> > relative ages. The major flaw in my code is that a sufficiently
> > long-lived
> > process becomes virtually immortal, even if it happens to spring a serious
> > leak after this time - the flaw in yours is that system processes
>
> I think this could
>> relative ages. The major flaw in my code is that a sufficiently
>> long-lived
>> process becomes virtually immortal, even if it happens to spring a serious
>> leak after this time - the flaw in yours is that system processes
>
>I think this could easily be fixed if you'd 'chop off' the runtime
Michel Wilson wrote:
>
> > relative ages. The major flaw in my code is that a sufficiently
> > long-lived
> > process becomes virtually immortal, even if it happens to spring a serious
> > leak after this time - the flaw in yours is that system processes
>
> I think this could easily be fixed i
Jonathan Morton wrote:
>
> Oh and BTW, I think Bit/sqr(seconds) is a perfectly acceptable unit for
> "badness". Think about it - it increases with pigginess and decreases with
> longevity. I really don't see a problem with it per se.
Right it's not a problem pre se, but as you already explain
> relative ages. The major flaw in my code is that a sufficiently
> long-lived
> process becomes virtually immortal, even if it happens to spring a serious
> leak after this time - the flaw in yours is that system processes
I think this could easily be fixed if you'd 'chop off' the runtime at a
>> >> Of course, I realised that. Actually, what the code does is take an
>> >> initial badness factor (the memory usage), then divide it using goodness
>> >> factors (some based on time, some purely arbitrary), both of which can be
>> >> considered dimensionless. Also, at the end, the absolute
>> Understood - my Physics courses covered this as well, but not using the
>> word "normalise".
>
>Be that as it may, Martin's comments about normalizing are nonsense.
>Rik's killer (at least in 2.4.3-pre7) produces a badness value that's
>a product of badness factors of various units. It then us
Jonathan Morton <[EMAIL PROTECTED]> writes:
>
> Understood - my Physics courses covered this as well, but not using the
> word "normalise".
Be that as it may, Martin's comments about normalizing are nonsense.
Rik's killer (at least in 2.4.3-pre7) produces a badness value that's
a product of badne
Uh... and aside from init, mission critical stuff... crond should never
get killed, it runs mission critical cleanup tasks..
If crond dies, might as well make the machine die in a lot of cases.. I
hate to miss my nightly database exports...
Getting to look more and more like we need some way to c
On Mon, Mar 26, 2001 at 01:33:05PM +0200, Ingo Oeser wrote:
> > The point being, my database shouldn't be selected for
> > termination. Nobody ever got fired for kill -9'ing netscape,
> > but Oracle is a different story. I urge you, consider the
> > patch.
>
> No, you got fired for not setting
On Sun, Mar 25, 2001 at 09:13:20PM -0500, Matthew Chappee wrote:
> The point being, my database shouldn't be selected for
> termination. Nobody ever got fired for kill -9'ing netscape,
> but Oracle is a different story. I urge you, consider the
> patch.
No, you got fired for not setting ulimits
> OK I just did it. as I already told I have "stress tested it" by
> Since I'm one day late up to my promise to provide this
> patch it's actually fascinating that already 4 people (in esp. not
> newbees requesting a new /proc entry for everything)
> for reassurance that I will indeed implement
On Sun, 25 Mar 2001, Martin Dalecki wrote:
> Rik van Riel wrote:
> > - the AGE_FACTOR calculation will overflow after the system has
> > an uptime of just _3_ days
>
> I esp. the behaviour will be predictable.
U ?
Rik
--
Virtual memory is like a game you can't win;
However, without VM th
>> I didn't quite understand Martin's comments about "not normalised" -
>> presumably this is some mathematical argument, but what does this actually
>> mean?
>
>Not mathematics. It's from physics. Very trivial physics, basic scool
>indeed.
>If you try to calculate some weightning
>factors which i
Jonathan Morton wrote:
>
> >- the AGE_FACTOR calculation will overflow after the system has
> > an uptime of just _3_ days
>
> Tsk tsk tsk...
>
> >Now if you can make something which preserves the heuristics which
> >serve us so well on desktop boxes and add something that makes it
> >also wor
Martin Dalecki wrote:
> Rik van Riel wrote:
> > - the comments are just too rude ;)
> > (though fun)
>
> That's only a matter for the "smooth" anglosaxons. Different
> cultures have different measures on this. I don't feel the need
> to adjust myself to the american cultural obstructivity.
> I
>- the AGE_FACTOR calculation will overflow after the system has
> an uptime of just _3_ days
Tsk tsk tsk...
>Now if you can make something which preserves the heuristics which
>serve us so well on desktop boxes and add something that makes it
>also work on your Oracle servers, then I'd be inte
Rik van Riel wrote:
>
> On Sun, 25 Mar 2001, Martin Dalecki wrote:
>
> > Ah... and of course I think this patch can already go directly
> > into the official kernel. The quality of code should permit
> > it. I would esp. request Rik van Riel to have a closer look
> > at it...
>
> - the algorith
On Sun, 25 Mar 2001, Martin Dalecki wrote:
> Ah... and of course I think this patch can already go directly
> into the official kernel. The quality of code should permit
> it. I would esp. request Rik van Riel to have a closer look
> at it...
- the algorithms are just as much black magic as th
19 matches
Mail list logo
