Sorry if I fork a bit the thread but I'm wondering why the load average is incremented
for each D process.
I don't know if the kernel use this information (if yes please let me know).
But some programs like sendmail use this information to sleep when the load is too
high (I believe from 12 for
The sleep should certainly be interruptible and I that's what I said to the GFS guy.
But what the reason to increment the load average for each D process ?
Thanks,
Christophe
On mer, 04 avr 2001 13:15:52 Alan Cox wrote:
> > The file locking use real IO and so when you ask for a lock, if the loc=
ote:
> On Wed, 4 Apr 2001, christophe barbe wrote:
>
> > The sleep should certainly be interruptible and I that's what I
> > said to the GFS guy. But what the reason to increment the load
> > average for each D process ?
>
> from a philosical POV: they are processe
On mer, 04 avr 2001 17:05:05 Paul Jakma wrote:
> imagine a box with a bunch of processes that do almost nothing but
> call on the kernel to do IO. If you only count the runnable state
> towards load_avg then your load_avg will be very low, even though your
> box is swamped - you are ignoring the w
This problem seems to be related with the recent post from David Howells
<[EMAIL PROTECTED]> with the subject "rw_semaphore bug".
Christophe
On mar, 03 avr 2001 18:40:53 Manfred Spraul wrote:
> > ps xl:
> > F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
> > 040 1000 1230 1 9 0 2432
Which kernel are you using ?
GFS use this kind of computation. And with kernel 2.2, a module divdi3.o provides all
missing symbol like __divdi3.
Christophe
On jeu, 05 avr 2001 16:09:14 Manoj Sontakke wrote:
> hi
>
> On Thu, 5 Apr 2001, Alexander Viro wrote:
> > On Thu, 5 Apr 2001, Manoj Sontak
in fs/block_dev.c block_read() function (in 2.2 and 2.4 series)
rblocks = blocks = (left + offset + blocksize - 1) >> blocksize_bits;
bhb = bhe = buflist;
if (filp->f_reada) {
if (blocks < read_ahead[MAJOR(dev)] / (blocksize >> 9))
blocks = read_ahead[MAJOR(dev)] / (blocks
I'm trying to scan the content of the /dev directory in a init_module function.
I've not found example in the kernel source. So I try to reproduce the work of the
system call.
I open the directory, check if the readdir pointer is not null in the f_op structure
and then use it with my filldir fun
Please Rik, could you explain what you mean with "reclaim swap space when we run out".
In my (limited) understanding, when there's no more free memory (ram and swap space),
the kernel starts to kill process (and the choice is a difficult point).
Are you proposing to add an API to reclaim swap ins
at it is to avoid fragmentation but this can lead to false OOM
situation (false because we have free memory in swap but it's reserved to avoid
fragmentation).
Christophe
On ven, 16 mar 2001 00:26:35 Rik van Riel wrote:
> On Thu, 15 Mar 2001, christophe barbe wrote:
>
> >
Which kernel are you using.
I've had a similar problem with 2.2.18.
I've backported 2.2.19pre changes to it.
(i.e. apply on 2.2.18 a diff of the file drivers/net/eepro100.c made between 2.2.18
and the last 2.2.19pre)
And since I've never seen this problem again.
Christophe
On jeu, 22 mar 2001
I've missed the thread "avoiding bad sleeps" last week. I've had a similar problem and
I would like to discuss the solution I've used to avoid it.
I want to wake up a sleeping process from an IRQ handler. In the process, if I use a
interruptible_sleep_on(), I need first to restore flags (otherw
ion.
Thank you,
Christophe Barbé
On lun, 05 fév 2001 13:59:28 Manfred Spraul wrote:
> christophe barbe wrote:
> >
> > I've missed the thread "avoiding bad sleeps" last week. I've had a similar problem
> > and I would like to discuss the solution I&#x
Ok it seems not important to have a nice boot process but each time you show a linux
machine to a M$ normal user (normal = not a programmer) his first reaction is
something like ""what are all these strange output lines?". And it's the first thing
that keep Windows user in the dark side.
Windo
On ven, 09 fév 2001 08:03:14 Mike Galbraith wrote:
> I hope that nothing like this is _ever_ integrated (and doubt I need
> be concerned;). IMHO, hiding output from users arrogantly assumes
> that they are too stupid/ignorant to have any use for such information.
Most user don't want to learn th
15 matches
Mail list logo
