On Mon, 25 Sep 2000, Alexander Viro wrote:
>
>
> On Sun, 24 Sep 2000, Linus Torvalds wrote:
>
> > The remaining part if the directory handling. THAT is very buffer-cache
> > intensive, as the directory handling hasn't been moved over to the page
> > cache at all for ext2. Doing a large
In message <[EMAIL PROTECTED]> you write:
> Hi,
>
> I've just spotted a small problem with 2.4.0-test8 running netfilter:
>
> NAT: 3 dropping untracked packet c065d3a0 1 192.168.0.1 -> 192.168.0.9
Yes. The connection tracking code doesn't try to understand broadcast
packets, so when it sees
On Sun, 24 Sep 2000, Linus Torvalds wrote:
> I'm not claiming that the buffer cache accesses would go away - I'm just
> saying that the unbalanced "only buffer cache" case should go away,
> because things like "find" and friends will still cause mostly page cache
> activity.
>
> (Considering
James Sutherland writes:
> On Sat, 23 Sep 2000, Russell King wrote:
> > And I'll try to make the point a second time that everything does not have
> > a character-based screen to write to.
>
> So what? For platforms which have a nice easy way to stick ASCII on
> screen, use this. For other
Hello,
I need to update the MAC address on a Intel 82559 ethernet card.
Tried:
# ifconfig eth0 down
# ifconfig eth0 hw ether0 xx:xx:xx:xx:xx:xx
# ifconfig eth0 up
It seems to take effect. Ping works. I have not had time to verify
whether the MAC address is changed on the wire.
When the
Hi David,
David Ford <[EMAIL PROTECTED]> writes:
> I think it's time to get Christoph on the line and see what he has
> to say. The 4096 number is a limit to the system, you can have a
> max of 4096 shared memory segments systemwide. Do you know offhand
> which programs are using(abusing)
On Mon, 25 Sep 2000, Mark Hahn wrote:
> > The problem is large numbers of threads in 2.4.0-test8 can result in a
> > hard crash of the entire kernel. This can be done as a non-root user.
>
> this appears to be reproducable (128M duron, haven't tried intel UP/SMP):
i've done some
On Mon, Sep 04, 2000 at 10:58:09PM +0200, Pedro M. Rodrigues wrote:
>
>The change to eepro100 done in pre16 isn´t listed as being
> restored. Is it still in i/o mode?
The investigation hasn't succeeded yet.
It looks like a timing problem (however, I'm not so sure now).
I spent 3 full
indeed, after changing max_queued_signals to 4096, i cannot crash the
kernel anymore with 2000 threads.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
btw., maybe it's init that gets those 2000 signals, not bash?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Ive written a small program to demonstrate the performance problems Ive
been seeing in recent Linux kernels.
The benchmark is a single process which writes and read 8k blocks
round-robin from a number of files.
It is written as a single process so the ordering of the operations is
known and
safemode <[EMAIL PROTECTED]> writes:
> The sum of the Bytes used in the 4096 entries ipcs shows is WAY off from the
> bytes used in df if that's what you wanted to know.df shows 109K in
> use... and that's easily beaten by the first entry in ipcs
>
> -- Shared Memory Segments
>
Donn Washburn wrote:
>
> I would request a "cc" message.
>
> It seems as recent I have either a memory problem and or possible
> kernel problem with this system. System is a ASUS P5A, AMD K6-II/350
> 128Meg/IDE system.
Don't use test8! It is known for cannibalism (particularly for eating
On Mon, 25 Sep 2000, Russell King wrote:
> James Sutherland writes:
> > On Sat, 23 Sep 2000, Russell King wrote:
> > > And I'll try to make the point a second time that everything does not have
> > > a character-based screen to write to.
> >
> > So what? For platforms which have a nice easy way
Greg,
On Sun, Sep 24, 2000 at 11:42:11PM -0700, Greg Zhang wrote:
> I need to update the MAC address on a Intel 82559 ethernet card.
> Tried:
>
> # ifconfig eth0 down
> # ifconfig eth0 hw ether0 xx:xx:xx:xx:xx:xx
> # ifconfig eth0 up
>
> It seems to take effect. Ping works. I have not had time
Ragnar Kjørstad wrote:
>
> On Fri, Sep 22, 2000 at 03:23:26PM -0700, Hans Reiser wrote:
> > I think Xuan's algorithm is good, so I want to add to it.:-)
> >
> > Ragnar, I don't understand your objection to it. It is always the
> > case that if you specify real
> > time constraints that are
Very correct except for one thing, allocation fails and ipcs -u shows
4097 when the limit shows 4096. safemode reports that eventually the
kernel crashes. This may be due to the test9 'features' and a side
affect, or it may be something to keep in mind once we get things nailed
down a bit.
-d
On Sun, 24 Sep 2000, Robert Redelmeier wrote:
> > I am trying to get the call trace of a process by tracing the return
> > addresses on the stack. To get the correct location of the return
> > address I need to know whether the kernel is being compiled with
> > frame pointer because this
> " " == Mike A Harris <[EMAIL PROTECTED]> writes:
> Are there any known problems with using a reiserfs patched
> 2.2.16 or 2.2.17 with the NFS patches? If not, does the patch
> order matter?
There's no problem with the client patches. As for mixing reiserfs +
knfsd, there
David Ford <[EMAIL PROTECTED]> writes:
> Very correct except for one thing, allocation fails and ipcs -u
> shows 4097 when the limit shows 4096. safemode reports that
> eventually the kernel crashes. This may be due to the test9
> 'features' and a side affect, or it may be something to keep in
On Mon, 25 Sep 2000 01:11:08 +0530 (IST),
Sushil <[EMAIL PROTECTED]> wrote:
>I agree. Sitting in the front of desktop I can see if the source files are
>getting compiled with or without -fomit-frame-pointer. But, while writing
>a function in a kernel source file, I want to know whether the
Keith Owens wrote:
>
> On Sat, 23 Sep 2000 14:15:44 +0100 (BST),
> James Sutherland <[EMAIL PROTECTED]> wrote:
> >How about putting these files in the modules directory? That way, we have
> >a nice consistent location for them.
>
> Why do you think modutils 2.3.14 added a prune list of files to
> The 2.4.x kernel series obtains its /proc/pci device name data from a
> data file pci.ids. The file makes PCI device name generic enough that
> it may be used by multiple utilities -- the kernel, Martin Mares'
> pciutils, distro installers, etc. The attached patch, against kernel
>
On Sun, 24 Sep 2000, Richard Henderson wrote:
> The PCI setup widgetry is known to be broken for pci-pci bridges.
>
> I've been intending to rewrite all this, but keep finding something
> more interesting to do -- like clean the cat box. If it makes you
> feel any better, I have an AS4100 that
On Fri, 22 Sep 2000, Jan-Benedict Glaw wrote:
> Instead of having hard-coded values, we should maybe do something
> more variable like:
> if (year >= (20 + YEARS_SINCE_2000) && year < (48 + YEARS_SINCE_2000)
> ...
This looks reasonable.
> YEARS_SINCE_2000 could be define'd through
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> Not sure if this is the right moment for those changes though, I'm not
> worried about ext2 but about the other non-netoworked fses that nobody
> uses regularly.
it *is* the right moment to clean these issues up. These kinds of things
are what
Hi all
I'm getting kernel oops if I try networking with bonding. I working with
2.2.16-smp and the bonding.c etc. included with it. Everything starts up but
as soon as a packet is sent (ping). I'm getting the following error:
Unable to handel kernel NULL pointer derefernce at virtual address
Hi there ...
I have the 2.2.17 Kernel with the VIA
Chipset Support. My BIOS says that my HD
(Samsung) is in UDMA Mode 4. A friend of
mine told me that I can increase my
disk performance a little if I use DMA.
hdparm -d 1 /dev/hda
But I will get the following errors whenever
I run hdparm -tT
On Mon, 25 Sep 2000 11:07:58 +0200 (CEST),
Andrzej Krzysztofowicz <[EMAIL PROTECTED]> wrote:
>BTW, what do you think of idea making the pci.ids base modular ?
>The module while loading should process the queue.
Does the modules.pcimap file creates by recent modules do what you
want? It maps
Hi all
I made a very small patch to the SysRq facility that signals
a program with SIGUSR1, the program is registered via sysctl
The signal is launched with Alt+SysRq+X (X stands for eXecute program)
/proc/sys/kernel/sysrq_progid contains pid and start_time
which totally identifies the
i'd also like to share my experiences with recent kernels, compared to the
'old VM'. I frequently run high VM load multi-gigabyte systems with alot
of IRQ-side allocations as well, and it's surprising how sensitive these
systems' performance is to VM balance, despite gobs of RAM.
- The biggest
On Mon, 25 Sep 2000, Martin Diehl wrote:
> PS: vmfixes-2.4.0-test9-B2 not yet tested - will do later.
Hi - done now:
using 2.4.0-t9p6 + vmfixes-2.4.0-test9-B2 I ended up with the box
deadlocked again! Was "make bzImage" on UP booted with mem=8M.
After about 4 hours at load 2-3 and almost
On Mon, Sep 25, 2000 at 11:35:35AM +0200, Maciej W. Rozycki wrote:
> On Fri, 22 Sep 2000, Jan-Benedict Glaw wrote:
>
> > Instead of having hard-coded values, we should maybe do something
> > more variable like:
> > if (year >= (20 + YEARS_SINCE_2000) && year < (48 + YEARS_SINCE_2000)
> >
On Mon, 25 Sep 2000, Andrzej Krzysztofowicz wrote:
> BTW, what do you think of idea making the pci.ids base modular ?
> I mean replacing data requests from pci.ids base by their queuing requests
> (+ eventually request_module(pci_ids) to process the queue if possible )
>
> The module while
On Sun, 24 Sep 2000 14:28:07 -0500 (CDT),
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>[Tigran Aivazian <[EMAIL PROTECTED]>]
>> The question you ask can be answered trivially - yes, it is
>> definitely a good idea, please make such a patch.
>
>My expression doesn't catch *all* offenders, by any
Sushil wrote:
>
> I agree. Sitting in the front of desktop I can see if the source files are
> getting compiled with or without -fomit-frame-pointer. But, while writing
> a function in a kernel source file, I want to know whether the caller of
> this function was compiled with or without
On Mon, 25 Sep 2000 06:21:48 -0500,
Robert Redelmeier <[EMAIL PROTECTED]> wrote:
>Ah -- I see, you are looking at some sort of kernel debugger. Well,
>then one way would be to look at entry and exit points. i386 Frame
>pointers are set up with `pushl %ebp / movl %esp, %ebp / subl $local,
> When the machine was rebooted, the new MAC address was lost.
> This seems to be a bug in the 82559 driver. 82559 spec specifies
The kernel address overrides never do permanent changes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Mon, 25 Sep 2000, pb wrote:
> Hi all
>
> I'm getting kernel oops if I try networking with bonding. I working with
> 2.2.16-smp and the bonding.c etc. included with it. Everything starts up but
> as soon as a packet is sent (ping). I'm getting the following error:
2.2.17 probably fixes this
>
> On Mon, 25 Sep 2000 11:07:58 +0200 (CEST),
> Andrzej Krzysztofowicz <[EMAIL PROTECTED]> wrote:
> >BTW, what do you think of idea making the pci.ids base modular ?
> >The module while loading should process the queue.
>
> Does the modules.pcimap file creates by recent modules do what you
>
On Mon, 25 Sep 2000, Martin Diehl wrote:
>
>
> On Mon, 25 Sep 2000, Martin Diehl wrote:
>
> > PS: vmfixes-2.4.0-test9-B2 not yet tested - will do later.
>
> Hi - done now:
>
> using 2.4.0-t9p6 + vmfixes-2.4.0-test9-B2 I ended up with the box
> deadlocked again! Was "make bzImage" on UP
On Mon, 25 Sep 2000, Andrzej Krzysztofowicz wrote:
> I mean moving the __init database compiled into kernel (based on pci.ids) to
> a separate module, which would be responsible for on-demand updating of text
> information (i.e. replacing VID:DID numbers with text).
In early 2.3.x, the fbdev
On Mon, 25 Sep 2000, Jeff Garzik wrote:
> I see you suggestion in the same way... If we keep the PCI device name
> data around after boot, then we have a lot of kernel memory locked up
> on the off chance that a HotPlug PCI device might appear for which we
> need a name.
> I would much prefer a
On Mon, 25 Sep 2000, Dan Hollis wrote:
> On Mon, 25 Sep 2000, Jeff Garzik wrote:
> > I see you suggestion in the same way... If we keep the PCI device name
> > data around after boot, then we have a lot of kernel memory locked up
> > on the off chance that a HotPlug PCI device might appear for
On Mon, 25 Sep 2000, Jan-Benedict Glaw wrote:
> ./driver/char/rtc.c:rtc_init()
> #if defined(__alpha__) || defined(__mips__)
> [...]
That is wrong. I fixed this partially in the MIPS/Linux CVS tree a few
weeks ago. The __mips__ conditional is to be completely removed.
> MIPS does that as
I get some oops whenever I try to insmod sb
here are some of them, in the hope that someone can track down the problem
Unable to handle kernel paging request at virtual address ca8fc1a0
ca88a49d
*pde = 07f8a063
Oops:
CPU:0
EIP:
On Sun, 24 Sep 2000, Matthew Dharm wrote:
> I'm the usb-storage maintainer. Yes, I realize that there is really no
> need to reset the state to TASK_RUNNING, but I felt better having those
> there. Considering that code is from the reset routines which almost never
> get called, I figured it
On Mon, Sep 25, 2000 at 12:13:08PM +0200, Ingo Molnar wrote:
>
> On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
>
> > Not sure if this is the right moment for those changes though, I'm not
> > worried about ext2 but about the other non-netoworked fses that nobody
> > uses regularly.
>
> it *is*
On Mon, Sep 25, 2000 at 12:42:09PM +0200, Ingo Molnar wrote:
> believe could simplify unrelated kernel code significantly. Eg. no need to
> check for NULL pointers on most allocations, a GFP_KERNEL allocation
> always succeeds, end of story. This behavior also has the 'nice'
Sorry I totally
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> Sorry I totally disagree. If GFP_KERNEL are garanteeded to succeed
> that is a showstopper bug. [...]
why?
> machine power for simulations runs out of memory all the time. If you
> put this kind of obvious deadlock into the main kernel allocator
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> Please fix raid1 instead of making things worse.
huh, what do you mean?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Here is a patch to arch/i386/traps.c and arch/i386/signal.c which does
what you are suggesting, I believe.
I have tested this and it works fine for me. (Though I do also need
the patch which stores dr6 back into current->thread.debugreg[6]. That
is not included here since I submitted it
On Mon, Sep 25, 2000 at 03:02:58PM +0200, Ingo Molnar wrote:
>
> On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
>
> > Sorry I totally disagree. If GFP_KERNEL are garanteeded to succeed
> > that is a showstopper bug. [...]
>
> why?
Because as you said the machine can lockup when you run out of
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> > yet another elevator algorithm we need a squeaky clean VM balancer above
>
> FYI: My current tree (based on 2.4.0-test8-pre5) delivers 16mbyte/sec
> in the tiobench write test compared to clean 2.4.0-test8-pre5 that
> delivers 8mbyte/sec
great!
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> > > Sorry I totally disagree. If GFP_KERNEL are garanteeded to succeed
> > > that is a showstopper bug. [...]
> >
> > why?
>
> Because as you said the machine can lockup when you run out of memory.
well, i think all kernel-space allocations have
On Mon, Sep 25, 2000 at 03:04:10PM +0200, Ingo Molnar wrote:
>
> On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
>
> > Please fix raid1 instead of making things worse.
>
> huh, what do you mean?
I mean this:
while (!( /* FIXME: now we are rather fault tolerant than nice */
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> > huh, what do you mean?
>
> I mean this:
>
> while (!( /* FIXME: now we are rather fault tolerant than nice */
this is fixed in 2.4. The 2.2 RAID code is frozen, and has known
limitations (ie. due to the above RAID1 cannot be used
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> Is it safe to sleep on the waitqueue in the kmalloc fail path in
> raid1?
yes. every RAID1-bh has a bound lifetime. (bound by worst-case IO
latencies)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Mon, Sep 25, 2000 at 03:12:58PM +0200, Ingo Molnar wrote:
> well, i think all kernel-space allocations have to be limited carefully,
When a machine without a gigabit ethernet runs oom it's userspace that
allocated the memory via page faults not the kernel.
And if the careful limit avoids the
The cciss driver is for our next generation of array controllers.
Besides adding the complexity of a single driver, there is also a question
of regression testing a single driver. The cpqarray driver has support for
all our controllers back to the EISA based controllers.
On Mon, Sep 25, 2000 at 03:21:01PM +0200, Ingo Molnar wrote:
> yes. every RAID1-bh has a bound lifetime. (bound by worst-case IO
> latencies)
Very good! Many thanks Ingo.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hello to all,
I have one doubt and is as below.
Suppose say the two drivers driver1 and driver2 will install the ISR for a
particular interrupt, say UART0.
After some time the interrupt is generated. At this moment, which driver's
ISR is going to execute ?.
If driver1 ISR is get executed,
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> And if the careful limit avoids the deadlock in the layer above
> alloc_pages, then it will also avoid alloc_pages to return NULL and
> you won't need an infinite loop in first place (unless the memory
> balancing is buggy).
yes i like this
On Mon, 25 Sep 2000, Mahadev K Cholachagudda wrote:
> Hello to all,
>
> I have one doubt and is as below.
>
>
> Suppose say the two drivers driver1 and driver2 will install the ISR for a
> particular interrupt, say UART0.
> After some time the interrupt is generated. At this moment, which
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> > yes. every RAID1-bh has a bound lifetime. (bound by worst-case IO
> > latencies)
>
> Very good! Many thanks Ingo.
this was actually coded/fixed by Neil Brown - so the kudos go to him!
Ingo
-
To unsubscribe from this list: send the
On Mon, Sep 25, 2000 at 03:10:51PM +0200, Ingo Molnar wrote:
> yep. But i dont understand why this makes any difference - the waitqueue
It makes a difference because your sleeping reads won't get the wakeup
even while they could queue their reserved read request (they have
to wait the FIFO to
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> - sync_page(page);
> set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> + sync_page(page);
> - run_task_queue(_disk);
> set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> +
Hi,
On Mon, Sep 25, 2000 at 04:02:30AM +0200, Andrea Arcangeli wrote:
> On Sun, Sep 24, 2000 at 09:27:39PM -0400, Alexander Viro wrote:
> > So help testing the patches to them. Arrgh...
>
> I think I'd better fix the bugs that I know about before testing patches that
> tries to remove the
On Mon, Sep 25, 2000 at 03:39:51PM +0200, Ingo Molnar wrote:
> Andrea, if you really mean this then you should not be let near the VM
> balancing code :-)
What I mean is that the VM balancing is in the lower layer that knows anything
about the per-socket gigabit ethernet skbs limits, the limit
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> Again: the bean counting and all the limit happens at the higher
> layer. I shouldn't know anything about it when I play with the lower
> layer GFP memory balancing code.
exactly, and this is why if a higher level lets through a GFP_KERNEL, then
On Mon, 25 Sep 2000, Mahadev K Cholachagudda wrote:
> Hello to all,
>
> I have one doubt and is as below.
>
>
> Suppose say the two drivers driver1 and driver2 will install the ISR for a
> particular interrupt, say UART0.
> After some time the interrupt is generated. At this moment, which
On Mon, 25 Sep 2000, Jens Axboe wrote:
> The changes made were never half-done. The recent bug fixes have
> mainly been to remove cruft from the earlier elevator and fixing a bug
> where the elevator insert would screw up a bit. So I'd call that fine
> tuning or adjusting, not fixing half-done
On Mon, Sep 25, 2000 at 03:57:31PM +0200, Ingo Molnar wrote:
> i had yesterday - those were simple VM deadlocks. I dont see any deadlocks
Definitely. They can't explain anything about the VM deadlocks. I was
_only_ talking about the blkdev hangs that caused you to unplug the
queue at each
On Mon, Sep 25 2000, Robert Cohen wrote:
> With kernel version 2.4.0-test9pre6 the results are as follows.
> The test machine has 128 Megs of memory. The tests accesses 240 Megs of
> files so that it can't fit in cache.
>
> If I run it with 8 files of size 30 Megs:
>
> [robert@test25 src]$
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> I was _only_ talking about the blkdev hangs [...]
i guess this was just miscommunication. It never 'hung', it just performed
reads with 20k/sec or so. (without any writes being done in the
background.) A 'hang' for me is a deadlock or lockup, not
On Mon, Sep 25 2000, Ingo Molnar wrote:
> > The changes made were never half-done. The recent bug fixes have
> > mainly been to remove cruft from the earlier elevator and fixing a bug
> > where the elevator insert would screw up a bit. So I'd call that fine
> > tuning or adjusting, not fixing
On Sun, 24 Sep 2000, Ingo Molnar wrote:
> i'm wondering about the following piece of code in refill_inactive():
>
> if (current->need_resched && (gfp_mask & __GFP_IO)) {
> __set_current_state(TASK_RUNNING);
> schedule();
>
On Mon, Sep 25, 2000 at 03:49:52PM +0200, Jens Axboe wrote:
> And a new elevator was introduced some months ago to solve this.
And now that I done some benchmark it seems the major optimization consists in
the implementation of the new _ordering_ algorithm in test2, not really from
the removal
thanx for the thip with 2.2.17, it really solved my problem. but know i'm
getting
SIOCSIFSLAVE: invalid agrument.
error's when trying to ifenslave devices. i know that this may be the wrong
place for a discussion on bonding, but i hardly can find any help on this.
because it's quite urgent to
On Mon, Sep 25 2000, Andrea Arcangeli wrote:
> > i had yesterday - those were simple VM deadlocks. I dont see any deadlocks
>
> Definitely. They can't explain anything about the VM deadlocks. I was
> _only_ talking about the blkdev hangs that caused you to unplug the
> queue at each reschedule
On Mon, Sep 25, 2000 at 04:04:14PM +0200, Ingo Molnar wrote:
> exactly, and this is why if a higher level lets through a GFP_KERNEL, then
> it *must* succeed. Otherwise either the higher level code is buggy, or the
> VM balance is buggy, but we want to have clear signs of it.
I'm not sure if we
On Mon, Sep 25 2000, Andrea Arcangeli wrote:
> > And a new elevator was introduced some months ago to solve this.
>
> And now that I done some benchmark it seems the major optimization consists in
> the implementation of the new _ordering_ algorithm in test2, not really from
> the removal of the
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> I'm not sure if we should restrict the limiting only to the cases that
> needs them. For example do_anonymous_page looks a place that could
> rely on the GFP retval.
i think an application should not fail due to other applications
allocating too
On Mon, Sep 25, 2000 at 04:08:38PM +0200, Jens Axboe wrote:
> The sg problem was different. When sg queues a request, it invokes the
> request_fn to handle it. But if the queue is currently plugged, the
> scsi_request_fn will not do anything.
That will explain it, yes. In the same way for
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> driver (and I very much hope that with EXCLUSIVE gone away and the
> wait_on_* fixed those hangs will go away because I don't see anything else
> wrong at this moment).
the EXCLUSIVE thing only optimizes the wakeup, it's not semantic! How
better
On Mon, Sep 25 2000, Andrea Arcangeli wrote:
> > The sg problem was different. When sg queues a request, it invokes the
> > request_fn to handle it. But if the queue is currently plugged, the
> > scsi_request_fn will not do anything.
>
> That will explain it, yes. In the same way for correctness
On Mon, Sep 25, 2000 at 04:11:34PM +0200, Jens Axboe wrote:
> Interesting. I haven't done any serious benching with the CSCAN introduction
> in elevator_linus, I'll try that too.
Only changing that the performance decreased reproducibly from 16 to 14
mbyte/sec in the read test with 2 threads.
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> I talked with Alexey about this and it seems the best way is to have a
> per-socket reservation of clean cache in function of the receive window. So we
> don't need an huge atomic pool but we can have a special lru with an irq
> spinlock that is
On Mon, 25 Sep 2000, Rik van Riel wrote:
> 2) you are right, we /can/ schedule when __GFP_IO isn't set, this is
>mistake ... now I'm getting confused about what __GFP_IO is all
>about, does anybody know the _exact_ meaning of __GFP_IO ?
__GFP_IO set to 1 means that the allocator can
On Mon, Sep 25, 2000 at 04:27:24PM +0200, Ingo Molnar wrote:
> i think an application should not fail due to other applications
> allocating too much RAM. OOM behavior should be a central thing and based
At least Linus's point is that doing perfect accounting (at least on the
userspace
>
> On Mon, 25 Sep 2000, Andrzej Krzysztofowicz wrote:
> > I mean moving the __init database compiled into kernel (based on pci.ids) to
> > a separate module, which would be responsible for on-demand updating of text
> > information (i.e. replacing VID:DID numbers with text).
>
> In early
[My first linux crash in over 3 years]
My linux box was set up for ipmasq with:
===
/sbin/modprobe ip_masq_ftp
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
/sbin/ipchains -M -S 7200 10 160
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> At least Linus's point is that doing perfect accounting (at least on
> the userspace allocation side) may cause you to waste resources,
> failing even if you could still run and I tend to agree with him.
> We're lazy on that side and that's global
On Mon, Sep 25, 2000 at 04:29:42PM +0200, Ingo Molnar wrote:
> There is no guarantee at all that the reader will win. If reads and writes
> racing for request slots ever becomes a problem then we should introduce a
> separate read and write waitqueue.
I agree. However here I also have a in
On Mon, Sep 25, 2000 at 04:18:54PM +0200, Jens Axboe wrote:
> The scsi layer currently "manually" does a list_add on the queue itself,
> which doesn't look too healthy.
It's grabbing the io_request_lock so it looks healthy for now :)
Andrea
-
To unsubscribe from this list: send the line
On Mon, Sep 25, 2000 at 11:26:48AM -0300, Marcelo Tosatti wrote:
> This thread keeps freeing pages from the inactive clean list when needed
> (when zone->free_pages < zone->pages_low), making them available for
> atomic allocations.
This is flawed. It's the irq that have to shrink the memory
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> On Mon, Sep 25, 2000 at 03:02:58PM +0200, Ingo Molnar wrote:
> > On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> >
> > > Sorry I totally disagree. If GFP_KERNEL are garanteeded to succeed
> > > that is a showstopper bug. [...]
> >
> > why?
>
>
On Mon, 25 Sep 2000, Andrea Arcangeli wrote:
> > the EXCLUSIVE thing was noticed by Dimitris i think, and it makes tons of
>
> Actually I'm the one who introduced the EXCLUSIVE thing there and I audited
sorry - i said it was *noticed* by Dimitris. (and sent to l-k IIRC)
Ingo
-
To
On Sat, Sep 23, 2000 at 09:01:04PM -0500, [EMAIL PROTECTED] wrote:
> Another interesting thing that I just noticed, I can still play music CD's in either
>drive.
>
I am currently seeing the same behaviour. My machine is up for
42 days now. Kernel 2.2.16-3 (RH 6.2). I am quite
> > Because as you said the machine can lockup when you run out of memory.
>
> well, i think all kernel-space allocations have to be limited carefully,
> denying succeeding allocations is not a solution against over-allocation,
> especially in a multi-user environment.
GFP_KERNEL has to be able
1 - 100 of 485 matches
Mail list logo
