I believe David Miller's latest zero-copy patches might help here.
In his patch, the pull-up buffer is now allocated near the top of stack
(in the sunrpc code), so it can be a blocking allocation.
This doesn't fix the core VM problems, but does relieve the pressure
_slightly_ on the VM (I a
Hi,
If two processes, sharing the same page tables, hit an unloaded vmalloc
address in the kernel at the same time, one of the processes is killed
(with the message "Unable to handle kernel paging request").
This occurs because the test on a vmalloc fault is too tight. On x86,
it contains;
Hi,
On a 4GB SMP box, configured with HIGHMEM support, making a 670G
(obviously using a volume manager) ext2 file system takes 12minutes (over
10minutes of sys time).
One problem is buffer allocations do not use HIGHMEM, but the
nr_free_buffer_pages() doesn't take this into account causing
b
Hi Neil, all,
The nfs daemons run holding the global kernel lock. They still hold
this lock over calls to file_op's read and write.
The file system kernel interface (FSKI) doesn't require the kernel lock
to be held over these read/write calls. The nfs daemons do not require
that the reads
On Thu, 22 Feb 2001, Neil Brown wrote:
> On Sunday February 18, [EMAIL PROTECTED] wrote:
> > Hi Neil, all,
> >
> > The nfs daemons run holding the global kernel lock. They still hold
> > this lock over calls to file_op's read and write.
> > [snip]
> > Dropping the kernel lock around read an
On Thu, 1 Mar 2001, Manfred Spraul wrote:
> Alan added a CONFIG options for FORCED_DEBUG slab debugging, but there
> is one minor problem with FORCED_DEBUG: FORCED_DEBUG disables
> HW_CACHEALIGN, and several drivers assume that HW_CACHEALIGN implies a
> certain alignment (iirc usb/uhci.c assumes
On Thu, 1 Mar 2001, Manfred Spraul wrote:
> Mark Hemment wrote:
> >
> > The original idea behind offset was for objects with a "hot" area
> > greater than a single L1 cache line. By using offset correctly (and to my
> > knowledge it has never been used
On Thu, 1 Mar 2001, Manfred Spraul wrote:
> Yes, I see the difference, but I'm not sure that it will work as
> intended.
> offset must be a multiple of the alignment, everything else won't work.
The code does force the offset to be a multiple of the alignment -
rounding the offset up. The ide
On Fri, 2 Mar 2001, Manfred Spraul wrote:
> Zitiere Mark Hemment <[EMAIL PROTECTED]>:
> > Could be a win on archs with small L1 cache line sizes (16bytes on a
> > 486) - but most modern processors have larger lines.
>
> IIRC cache colouring was introduced for some
Hi Paul,
> 2) Other block I/O output (eg dd if=/dev/zero of=/dev/sdi bs=4M) also
> run very slowly
What do you notice when running "top" and doing the above?
Does the "buff" value grow high (+700MB), with high CPU usage?
If so, I think this might be down to nr_free_buffer_pages().
This fu
Hi,
Looking at the second loop in elevator_linus_merge(), it is possible for
requests to have their elevator_sequence go negative. This can cause a
v long latency before the request is finally serviced.
Say, for example, a request (in the queue) is jumped in the first loop
in elevator_linus
Hi,
On Thu, 28 Dec 2000, David S. Miller wrote:
>Date: Thu, 28 Dec 2000 23:17:22 +0100
>From: Andi Kleen <[EMAIL PROTECTED]>
>
>Would you consider patches for any of these points?
>
> To me it seems just as important to make sure struct page is
> a power of 2 in size, with the
On Fri, 29 Dec 2000, Tim Wright wrote:
> Yes, this is a very important point if we ever want to make serious use
> of large memory machines on ia32. We ran into this with DYNIX/ptx when the
> P6 added 36-bit physical addressing. Conserving KVA (kernel virtual address
> space), became a very high p
Hi,
On Mon, 25 Sep 2000, Stephen C. Tweedie wrote:
> So you have run out of physical memory --- what do you do about it?
Why let the system get into the state where it is neccessary to kill a
process?
Per-user/task resource counters should prevent unprivileged users from
soaking up too many
Hi Tigran,
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
> malfunctioning, interrupts are generated but no traffic gets through (YES,
> I did plug it in correctly, this time, and I repeat 2.2.16 works!)
I saw this the oth
Hi,
Two performance changes against 2.4.3.
flush_all_zero_pkmaps() is guarding against a race which cannot happen,
and thus hurting performance.
It uses the atomic fetch-and-clear "ptep_get_and_clear()" operation,
which is much stronger than needed. No-one has the page mapped, and
cannot
Hi,
I've never seen these trigger, but they look theoretically possible.
When processing the completion of a SCSI request in a bottom-half,
__scsi_end_request() can find all the buffers associated with the request
haven't been completed (ie. leftovers).
One question is; can this ever happ
Hi,
Several places in the kernel run holding the global kernel lock when it
isn't needed. This usually occurs when where is a function which can be
called via many different paths; some holding the lock, others not.
Now, if a function can block (and hence drop the kernel lock) the caller
ca
Hi Jens,
I ran this (well, cut-two) on a 4-way box with 4GB of memory and a
modified qlogic fibre channel driver with 32disks hanging off it, without
any problems. The test used was SpecFS 2.0
Peformance is definitely up - but I can't give an exact number, as the
run with this patch was com
On Wed, 30 May 2001, Jens Axboe wrote:
> On Wed, May 30 2001, Mark Hemment wrote:
> > Hi Jens,
> >
> > I ran this (well, cut-two) on a 4-way box with 4GB of memory and a
> > modified qlogic fibre channel driver with 32disks hanging off it, without
> > any pr
Hi Jens, all,
In drivers/block/ll_rw_blk.c:blk_dev_init(), the high and low queued
sectors are calculated from the total number of free pages in all memory
zones. Shouldn't this calculation be passed upon the number of pages upon
which I/O can be done directly (ie. without bounce pages)?
On
and scsi_merge.c) but no one posted any feedback.
I've included some of the original message below.
Mark
--
>From [EMAIL PROTECTED] Sat Mar 31 16:07:14 2001 +0100
Date: Sat, 31 Mar 2001 16:07:13 +0100 (BST)
From: Mark Hemmen
On Wed, 30 May 2001, Jens Axboe wrote:
> On Wed, May 30 2001, Mark Hemment wrote:
> > This can lead to attempt_merge() releasing the embedded request
> > structure (which, as an extract copy, has the ->q set, so to
> > blkdev_release_request() it looks like a reque
On Sun, 8 Jul 2001, Linus Torvalds wrote:
> On Sun, 8 Jul 2001 [EMAIL PROTECTED] wrote:
> >
> > mm/highmem.c/copy_from_high_bh() blocks interrupts while copying "down"
> > to a bounce buffer, for writing.
> > This function is only ever called from create_bounce() (which cannot
> > be called fr
Marcelo,
Infact, the test can be made even weaker than that.
We only what to avoid the inactive-clean list when allocating from
within an interrupt (or from a bottom-half handler) to avoid
deadlock on taking the pagecache_lock and pagemap_lru_lock.
Note: no allocations are done while hold
Hi,
d_move() in fs/dcache.c is checking the kernel lock is held
(switch_names() does the same, but is only called from d_move()).
My question is why?
I can't see what it is using the kernel lock to sync/protect against.
Anyone out there know?
Thanks,
Mark
-
To unsubscribe from this li
In 2.4.3pre6, code in page_alloc.c:__alloc_pages(), changed from;
try_to_free_pages(gfp_mask);
wakeup_bdflush();
if (!order)
goto try_again;
to
try_to_free_pages(gfp_mask);
wakeup_bdflush();
goto try_again;
This introduced the
On Wed, 9 May 2001, Marcelo Tosatti wrote:
> On Wed, 9 May 2001, Mark Hemment wrote:
> > Could introduce another allocation flag (__GFP_FAIL?) which is or'ed
> > with a __GFP_WAIT to limit the looping?
>
> __GFP_FAIL is in the -ac tree already and it is being u
On Fri, 11 May 2001, null wrote:
> Time to mkfs the same two 5GB LUNs in parallel is 54 seconds. Hmmm.
> Bandwidth on two CPUs is totally consumed (99.9%) and a third CPU is
> usually consumed by the kupdated process. Activity lights on the storage
> device are mostly idle during this time.
On Tue, 8 May 2001, David S. Miller wrote:
> Actually, the change was made because it is illogical to try only
> once on multi-order pages. Especially because we depend upon order
> 1 pages so much (every task struct allocated). We depend upon them
> even more so on sparc64 (certain kinds of p
30 matches
Mail list logo
