On Thu, May 03, 2001 at 06:46:10PM +0200, Andrea Arcangeli wrote:
as well. The only annoying thing is that UP kernel compiles seems not to
boot but I hope that will be fixed soon too.
Ok I spotted and fixed that bug that forbidden my tree to boot with UP
compiles on alpha. The bug
This fixes corruption with MAP_SHARED on top of nfs filesystem in 2.4:
--- 2.4.5pre1aa2/fs/nfs/write.c.~1~ Tue May 1 19:35:29 2001
+++ 2.4.5pre1aa2/fs/nfs/write.c Tue May 8 02:04:15 2001
@@ -1533,6 +1533,7 @@
if (!inode file)
inode = file-f_dentry-d_inode;
+
This night I moved the blkdev layer in pagecache in this patch:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.5pre1/blkdev-pagecache-1
It is incremental and depends on the o_direct functionality, latest
o_direct patch against 2.4.5pre1 is here:
On Wed, May 09, 2001 at 11:13:33AM +0200, Martin Dalecki wrote:
(buffered and direct) to work with a 4096 bytes granularity instead of
You mean PAGE_SIZE :-).
In my first patch it is really 4096 bytes, but yes I agree we should
change that to PAGE_CACHE_SIZE. The _only_ reason it's 4096
On Wed, May 09, 2001 at 09:30:18AM +0200, Trond Myklebust wrote:
Here therefore is Andrea's patch with the changes I propose. Opinions?
flushing the dirty pages before locks is probably not required, a dirty
page in the dirty_pages list is no different than a mapped page not in
the dirty_pages
On Wed, May 09, 2001 at 04:14:52PM +0200, Jens Axboe wrote:
better to stay with PAGE_CACHE_SIZE and not get into dark country :-)
My whole point for not using PAGE_CACHE_SIZE as virtual blocksize is
that many architectures have a PAGE_CACHE_SIZE 4k, up to 64k, on
x86-64 we may even hack a 2M
On Wed, May 09, 2001 at 04:12:41PM +0200, Cabaniols, Sebastien wrote:
Hi lkml,
There is likely a bug in the management of memory above two Gigabytes and
DMA in kernel 2.4.4
(up to ac-6) with the alpha. :-(
remeber why last yaer I was advocating a CONFIG_HIGHMEM option also in
2.4 and not
On Wed, May 09, 2001 at 05:03:06PM +0200, Reto Baettig wrote:
Jeff Garzik schrieb:
Martin Dalecki wrote:
- I force the virtual blocksize for all the blkdev I/O
(buffered and direct) to work with a 4096 bytes granularity instead of
You mean PAGE_SIZE :-).
Or maybe 8192
On Wed, May 09, 2001 at 07:02:16PM -0300, Marcelo Tosatti wrote:
Why don't you clean I_DIRTY_PAGES ?
we don't have visibilty on the inode_lock from there, we could make a
function in fs/inode.c or export the inode_lock to do that, but the flag
will be collected when the inode is released
On Wed, May 09, 2001 at 07:38:01PM -0300, Marcelo Tosatti wrote:
On Thu, 10 May 2001, Andrea Arcangeli wrote:
On Wed, May 09, 2001 at 07:02:16PM -0300, Marcelo Tosatti wrote:
Why don't you clean I_DIRTY_PAGES ?
we don't have visibilty on the inode_lock from there, we could make
On Sun, May 27, 2001 at 09:08:51PM +0200, Ingo Molnar wrote:
i took at look at your ksoftirq stuff yesterday, and i think it's
completely unnecessery and adds serious overhead to softirq handling. The
whole point of softirqs is to have maximum scalability and no
serialization. Why did you add
Anybody running on a machine with some zone empty (16Mbyte boxes (PDAs),
1G x86 with highmem enabled kernel or an arch with an iommu like alpha)
probably noticed that the MM was unusable on those hardware
configurations (as I also incidentally mentioned a few times on l-k in
the last months).
On Tue, Jun 05, 2001 at 04:16:57PM -0700, Linus Torvalds wrote:
but I think we should also make the init code clear the zone data for
empty zones so that these kinds of use uninitialized stuff things cannot
happen. No?
that would fix it too indeed, OTOH I think changing the empty zone
On Mon, May 21, 2001 at 11:42:16AM +0200, Andi Kleen wrote:
[actually most IA32 boxes already have one in form of the AGP GART, it's just
not commonly used for serious things yet]
I can be really wrong on this because I didn't checked anything about
the GART yet but I suspect you cannot use
in pre2 ret_from_exception reschedule and handle signals even if it is
returning to kernel code. rescheduling was not so obviously broken (at
least not for the page fault ;) but it just slowdown the code as I just
have all the necessary explicit checks in copy-user itself (which are
needed
On Mon, Jun 11, 2001 at 12:09:03PM -0700, Linus Torvalds wrote:
The copy-user latency fixes only make sense for out-of-line copies. If
we're going to have a conditional function call to schedule(), we do not
want to inline the dang thing any more - we've just destroyed our register
set etc
) around the scheduler prologue.
Only in 2.4.5aa3: expand-stack-smp-1
Do the checks inside the critical section to avoid races.
-
On Sat, May 26, 2001 at 07:33:10PM +0200, Andrea Arcangeli wrote:
I merged Rik's three
On Tue, Jun 12, 2001 at 04:27:33PM -0700, Richard Henderson wrote:
We fixed a bug in cv-qualification checking.
timer.c:35: conflicting types for `xtime'
include/linux/sched.h:540: previous declaration of `xtime'
There's no need for the volatile qualification here. One, being a
struct
There are a number of changes in kernel API visisble to userspace that
are unregistered in 2.4 mainline. I recommend to merge them ASAP to
avoid generating collisions across different versions of the kernel.
I'll attach here a number of patches that should make us to return in
sync. They must be
On Thu, Jun 14, 2001 at 07:12:19PM +0200, Andrea Arcangeli wrote:
is not definitive yet, O_DIRECTIO of tru64 is our O_NOFOLLOW so we're
just screwed as we just need a wrapper anyways to make complex programs like
I just got the email from Richard that he prefers to break O_NOFOLLOW
than
On Thu, Jun 14, 2001 at 07:16:34PM +0200, Andrea Arcangeli wrote:
I just got the email from Richard that he prefers to break O_NOFOLLOW
Richard are you sure we can break O_NOFOLLOW and still expect the machine to
boot?
./elf/cache.c: fd = open (temp_name, O_CREAT|O_WRONLY|O_TRUNC|O_NOFOLLOW
On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote:
They don't hurt but it's also a bad precedent - you don't want to add a
ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree.
disagree with this patch.
If tux will ever be merged into mainline eventually I don't
On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
within glibc, and (2) making these accesses slower since they
will be considered O_DIRECT after the change.
and then read/write will return -EINVAL which is life-threatening.
O_DIRECT like rawio via /dev/raw imposes special
On Thu, Jun 14, 2001 at 01:52:44PM -0400, Jeff Garzik wrote:
You're missing the point -- it's a bad precedent.
How many kernel forks and patches exist out there on the net?
How many of them are applied to 90% of kernels running out there? How
many of them will get merged eventually? How many
On Thu, Jun 14, 2001 at 07:47:57PM +0200, Andrea Arcangeli wrote:
On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote:
within glibc, and (2) making these accesses slower since they
will be considered O_DIRECT after the change.
and then read/write will return -EINVAL which
Diff between 2.4.6pre2aa2 and 2.4.6pre3aa1:
-
Moved on top of 2.4.6pre3.
Only in 2.4.6pre2aa2: 00_alpha-compile-swapon-1
Only in 2.4.6pre2aa2: 00_x86-entry.S-fix-1
Merged in 2.4.6pre3.
Only in 2.4.6pre3aa1:
On Mon, Jun 18, 2001 at 12:14:01PM +0200, German Gomez Garcia wrote:
Hello,
I've running 2.4.5-ac15 for almost a day (22 hours) and I found
some strange behaviour of the kswap, at least it was not present in
2.4.5-ac9. The swap memory increase with time as the cache dedicated
On Mon, Jun 18, 2001 at 03:34:43PM +0200, Luigi Genoni wrote:
Maybe there could be some HW related reason because of which it fixed for
yes, most probably he didn't had any zone empty so the fix couldn't make
a difference for him. German, can you confirm? (if you don't know what
it means just
On Mon, Jun 18, 2001 at 10:37:21AM -0300, Rik van Riel wrote:
Yes, this is expected behaviour with -ac14, -pre3 and newer.
If that means anything that doesn't happen here based on pre3.
Andrea
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Mon, Jun 18, 2001 at 10:43:14AM -0300, Rik van Riel wrote:
On Mon, 18 Jun 2001, Andrea Arcangeli wrote:
either apply this patch to 2.4.5ac15:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.5aa3/00_fix-unusable-vm-on-alpha-1
That one has already been
On Mon, Jun 18, 2001 at 11:54:09AM -0300, Rik van Riel wrote:
YOUR PATCH fixes a real bug, true. But that wasn't
what German was complaining about ;)
How did you know that before he made his first reply to my email?
Andrea
-
To unsubscribe from this list: send the line unsubscribe
On Mon, Jun 18, 2001 at 01:44:29PM -0300, Rik van Riel wrote:
On Mon, 18 Jun 2001, Andrea Arcangeli wrote:
On Mon, Jun 18, 2001 at 11:54:09AM -0300, Rik van Riel wrote:
YOUR PATCH fixes a real bug, true. But that wasn't
what German was complaining about ;)
How did you know
Diff between 2.2.20pre2aa1 and 2.2.20pre3aa1 (besides moving on top of
2.2.20pre3 that notably fixes the ptrace local DoS races):
Only in 2.2.20pre2aa1: 00_andi-mark_bh-1
Merged in 2.2.20pre3.
Only in 2.2.20pre3aa1:
On Wed, Jun 20, 2001 at 10:18:10PM +1000, Paul Mackerras wrote:
Well if they are relying on having a lot of stack available then those
places are buggy. Once the softirq is made pending it can run at any
it's not about having lots of stack available, it's about avoiding
recursion.
Andrea
-
Diff between 2.4.6pre3aa1 and 2.4.6pre3aa2:
Only in 2.4.6pre3aa2: 00_alpha-numa-initrd-1
Release initrd memory from right numa node.
(recommended)
Only in 2.4.6pre3aa2: 00_alpha-srm-2.4.6-pre1-1
Access the srm variables via /proc/srm_environment.
Patch posted
Diff between 2.2.20pre3aa1 and 2.2.20pre5aa1:
Only in 2.2.20pre3aa1: 00_newboot-2.2.20-pre2-1.diff.gz
Merged in 2.2.20pre5.
Only in 2.2.20pre3aa1: 00_mips-irix-dumpable-1
Not needed anymore with the do_coredump() common code.
Only in 2.2.20pre3aa1:
On Thu, Jun 21, 2001 at 04:39:11PM +0200, [EMAIL PROTECTED] wrote:
Hi,
I ran into some problems with buffer.c trying to unlock a page of
sorry for the huge delay in the answer, I was going to answer your
previous two emails very shortly (I didn't forgotten ;).
async io buffer heads
On Thu, Jun 21, 2001 at 11:16:42AM -0400, Chris Mason wrote:
Think of a mixture of fsync_inode_buffers and async i/o on page. Since
fsync_inode_buffers uses ll_rw_block, if that end_io handler is the last to
run the page never gets unlocked.
correct
Andrea
-
To unsubscribe from this list:
On Thu, Jun 21, 2001 at 04:39:11PM +0200, [EMAIL PROTECTED] wrote:
diff -ruN old/fs/buffer.c new/fs/buffer.c
--- old/fs/buffer.c Thu Jun 21 09:47:20 2001
+++ new/fs/buffer.c Thu Jun 21 10:44:01 2001
@@ -798,11 +798,12 @@
* that unlock the page..
*/
On Thu, Jun 21, 2001 at 09:54:47AM -0700, Linus Torvalds wrote:
The above _will_ break. tmp may be locked due to the write - and the
indeed, I missed the pending writes sorry.
Andrea
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
What's the problem with the existing code, and why do people want to add a
(unnecessary) new bit?
there's no problem with the existing code, what I understood is that
they cannot overwrite the -b_end_io callback in the lowlevel
On Thu, Jun 21, 2001 at 07:15:22PM +0200, Andrea Arcangeli wrote:
On Thu, Jun 21, 2001 at 09:56:04AM -0700, Linus Torvalds wrote:
What's the problem with the existing code, and why do people want to add a
(unnecessary) new bit?
there's no problem with the existing code, what I understood
Diff between 2.4.6pre3aa2 and 2.4.6pre5aa1:
-
Moved on top of 2.4.6pre5.
Only in 2.4.6pre3aa2: 00_alpha-warnings-1
Only in 2.4.6pre3aa2: 00_backout-udelay-1
Only in 2.4.6pre3aa2: 00_locks-1
Only in 2.4.6pre3aa2:
1. Userland programs which request kernel services via normal system
^^
calls *are not* to be considered derivative works of the kernel.
Please, at least don't say normal or it will be non obvious that it is
ok for the vsyscalls
On Wed, Jun 20, 2001 at 01:33:19PM +1000, Paul Mackerras wrote:
Well, I object to the without thinking bit. [..]
agreed, apologies.
BHs disabled is buggy - why would you want to do that? And if we do
tasklet_schedule
want to allow that, shouldn't we put the check in raise_softirq or the
On Tue, Jun 26, 2001 at 10:47:12AM -0400, Bulent Abali wrote:
Andrea,
I would like try your patch but so far I can trigger the bug only when
running TUX 2.0-B6 which runs on 2.4.5-ac4. /bulent
to run tux you can apply those patches in `ls` order to 2.4.6pre5aa1:
On Tue, Jun 26, 2001 at 06:22:15PM +0200, Jens Axboe wrote:
Hi,
I updated the patches to 2.4.6-pre5, and removed the zone-dma32
addition. This means that machines with 4GB of RAM will need to go all
good, we can relax the ZONE_NORMAL later, that's a separate problem with
skipping the
On Wed, Jun 27, 2001 at 10:18:26PM +0800, Zeng Yu wrote:
Hi all,
I think find a ramdisk bug of 2.4.4 kernel -- ramdisk
use both buffers and cached mem of the same size, thus
double the mem use.
mke2fs -m0 /dev/ram1
mount /dev/ram1 /mnt
dd if=/dev/zero of=/mnt/data bs=1k count=11
On Wed, Jun 27, 2001 at 10:08:15AM -0500, Adam wrote:
hello,
I have question. I have box with kernel 2.2.17pre15
upgrade to 2.2.19 or 2.2.20pre
Andrea
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Wed, Jun 27, 2001 at 06:49:08PM +0200, Jens Axboe wrote:
On Wed, Jun 27 2001, Jens Axboe wrote:
I can see one mm corruption race condition in the patch, you missed
nested irq in the for kmap_irq_bh (PIO). You must _always_
__cli/__save_flags before accessing the KMAP_IRQ_BH slot, in
On Fri, Jun 29, 2001 at 02:39:00AM -0700, Dan Kegel wrote:
At work I had to sit through a meeting where I heard
the boss say If Linux makes Sybase go through the page cache on
reads, maybe we'll just have to switch to Solaris. That's
a serious performance problem.
All I could say was I
On Wed, Jul 04, 2001 at 11:28:17PM +0200, Manfred H. Winter wrote:
Hi!
I tried to install kernel 2.4.6 with same configuration as 2.4.5, but
booting failed with:
kernel BUG at softirq.c:206!
do you have any problem with those patches applied?
On Thu, Jul 05, 2001 at 03:36:29PM +0100, Arjan van de Ven wrote:
Andrea Arcangeli wrote:
On Wed, Jul 04, 2001 at 11:28:17PM +0200, Manfred H. Winter wrote:
Hi!
I tried to install kernel 2.4.6 with same configuration as 2.4.5, but
booting failed with:
kernel BUG
On Fri, Jul 06, 2001 at 12:28:15AM +1000, Andrew Morton wrote:
ext3 journals data. That's unique and it breaks things (or rather,
things break it). It'd be trivial to support O_DIRECT in ext3's
writeback mode (metadata-only), but nobody uses that.
I thought everybody uses metadata-only to
On Thu, Jul 05, 2001 at 11:46:33AM -0400, Arjan van de Ven wrote:
On Thu, Jul 05, 2001 at 11:32:00PM +0800, Thibaut Laurent wrote:
And the winner is... Andrea. Kudos to you, I've just applied these patches,
recompiled and it seems to work fine.
Too bad, this was the perfect excuse for
While I was travelling disconnected from the internet the last week (I
will buy a GPRS phone soon ;) I also spotted and fixed the __GFP_BUFFER
deadlock that I was triggering on my 128m laptop while browsing large
email folders on top of crypto loop:
--- 2.4.6pre6aa1/include/linux/mm.h.~1~ Sat
Only rediffed (maintenance mode, no known bugs, alpha rtc thing not
merged yet).
---
Difference between 2.2.20pre5aa1 and 2.2.20pre7aa1:
Only in 2.2.20pre5aa1: 00_K7_P4-cachelines-4
Only in 2.2.20pre7aa1: 00_K7_P4-cachelines-5
Fixup
The main new thing is the blkdev in pagecache by default (not in the
experimental dir anymore). Ramdisk and initrd should work fine now
(initrd is untested though). It also fixes a vm deadlock and merges uml
from -ac.
Diff between
On Fri, Jul 06, 2001 at 03:08:05AM -0400, Jeff Garzik wrote:
Ville Nummela wrote:
In kernel/softirq.c, line 178:
if (test_bit(TASKLET_STATE_SCHED, t-state))
tasklet_schedule(t);
What's the idea behind this line? If the tasklet is already
On Fri, Jul 06, 2001 at 04:25:49AM -0400, Jeff Garzik wrote:
Jeff Garzik wrote:
The only thing that appears fishy is that if the tasklet constantly
reschedules itself, it will never leave the loop AFAICS. This affects
tasklet_hi_action as well as tasklet_action.
As I hacked around to
On Thu, Jul 05, 2001 at 11:32:00PM +0800, Thibaut Laurent wrote:
And the winner is... Andrea. Kudos to you, I've just applied these patches,
recompiled and it seems to work fine.
can you apply this patch on top of the ksoftirqd patch and see if you
can trigger the BUG() again when based on
On Wed, Jun 27, 2001 at 07:12:29PM +0200, Jens Axboe wrote:
Humm yes, I agree. I'll redo it tonight and send an updated
incremental. Hopefully I'll be able to upload a new full version too.
I was going to integrate the avoid-bounce-buffer support but I don't
find anything recent except the bio
On Fri, Jul 06, 2001 at 03:45:52PM +0200, Jens Axboe wrote:
Will do, but it will probably be after the weekend jfyi.
Fine with me, thanks!
take your time and have fun,
Andrea
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On Fri, Jul 06, 2001 at 10:18:53PM +0800, Thibaut Laurent wrote:
Confirmed. I tried both pre2 and pre3
2.4.7-pre2 + 00_ksoftirqd-7 + your last bug patch -- boot failed
2.4.7-pre3 + 00_ksoftirqd-7 + your last bug patch -- boot ok
perfect.
BTW, is there some kind of doc regarding all the
On Wed, Jan 24, 2001 at 04:05:12PM +0100, Sasi Peter wrote:
This isn't obvious. Your working may not fit in cache and so the kernel
understand it's worthless to swapout stuff to make space to a polluted
cache.
But your understanding agrees on that the larger chunks for each stream
we
On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote:
Hi,
On Mon, 29 Jan 2001, Andi Kleen wrote:
You can miss wakeups. The standard pattern is:
get locks
add_wait_queue(waitqueue, wait);
for (;;) {
if (condition you're waiting for is true)
On Mon, Jan 29, 2001 at 09:35:53PM +0100, Andi Kleen wrote:
On Mon, Jan 29, 2001 at 08:47:50PM +0100, Roman Zippel wrote:
You still miss wakeups. :)
And there was another race in it, I know. The first __set_task_state
has to be set_task_state to get the right memory write order on SMP.
On Fri, Feb 16, 2001 at 10:53:51AM -0500, David Mansfield wrote:
This may be a bit OT, but when you say O_DIRECT, that implies that you
can pass that flag to open(2) and it will bypass the page cache, and
yes.
read directly into user-space buffers (zero-copy IO)? Does this also
yes.
On Fri, Feb 16, 2001 at 04:44:48AM -0800, Theodore Y. Ts'o wrote:
Note that this only shows up when using mke2fs to create very large
filesystems, and you have relatively little memory. In this particular
If you can reproduce the oom of mke2fs on recent 2.2.19pre, could you try
again after
On Mon, Feb 19, 2001 at 11:05:23PM -0200, Marcelo Tosatti wrote:
--- linux/mm/filemap.c.orig Mon Feb 19 23:51:02 2001
+++ linux/mm/filemap.c Mon Feb 19 23:51:33 2001
@@ -611,11 +611,11 @@
add_wait_queue(page-wait, wait);
do {
- sync_page(page);
On Tue, Feb 20, 2001 at 09:11:04AM -0800, Linus Torvalds wrote:
Even if it is wake-one, others may have claimed it before. There can be
new users coming in and doing a "trylock()" etc.
NEVER *EVER* think that "exclusive wait-queue" implies some sort of
critical region protection. An
On Tue, Feb 20, 2001 at 05:31:25PM -0700, Andreas Dilger wrote:
The reason why the IOP was changed was because the VG_CREATE ioctl now
depends on the vg_number in the supplied vg_t to determine which VG minor
number to use. The old interface used the minor number of the opened
device inode,
On Tue, Feb 20, 2001 at 10:49:07PM +, Heinz Mauelshagen wrote:
Hi all,
a tarball of the Linux Logical Volume Manager 0.9.1 Beta 5 is available now at
http://www.sistina.com/
for download (Follow the "LVM download page" link).
This release fixes several bugs.
See the
On Wed, Feb 21, 2001 at 02:49:17PM +1100, Richard Gooch wrote:
You definately can mknod(2) on devfs. [..]
So then why don't we simply create the VG ourself with the right minor number
and use it as we do without devfs? We'll still have a global 256 VG limit this
way but that's not a minor
On Wed, Feb 21, 2001 at 11:28:39PM +, Alan Cox wrote:
[..] only when creating _very_ large file
systems with little memory, where the write throttling may still need a bit
of work.
I posted here a few days ago a little patch that is meant to address that. I
didn't got any feedback on it
On Thu, Feb 22, 2001 at 06:40:48PM -0200, Marcelo Tosatti wrote:
You want to throttle IO if the amount of on flight data is higher than
a given percentage of _main memory_.
As far as I can see, your patch avoids each individual queue from being
bigger than the high watermark (which is a
On Thu, Feb 22, 2001 at 11:57:00PM +0100, Andrea Arcangeli wrote:
unsane to wait kupdate to submit 10G of ram to a single harddisk before
unplugging on a 30G machine.
actually kupdate will unplug itself the queue but in theory it can grow the
queue still up to such level after the I/O started
On Thu, Feb 22, 2001 at 07:44:11PM -0200, Marcelo Tosatti wrote:
The global limit on top of the per-queue limit sounds good.
Probably.
Since you're talking about the "total_ram / 3" hardcoded value... it
should be /proc tunable IMO. (Andi Kleen already suggested this)
Yes, IIRC Andi also
On Mon, Apr 02, 2001 at 02:40:01PM +0300, Andrejs Dubovskis wrote:
[linux] make dep;make clean;make boot
...
gcc -D__KERNEL__ -I/usr/src/linux-2.4.3/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6 -c -o
On Wed, Apr 04, 2001 at 03:34:22PM +0200, Ingo Molnar wrote:
On Wed, 4 Apr 2001, Hubertus Franke wrote:
Another point to raise is that the current scheduler does a exhaustive
search for the "best" task to run. It touches every process in the
runqueue. this is ok if the runqueue length
On Wed, Apr 04, 2001 at 10:03:10AM -0400, Hubertus Franke wrote:
I understand the dilemma that the Linux scheduler is in, namely satisfy
the low end at all cost. [..]
We can satisfy the low end by making the numa scheduler at compile time (that's
what I did in my patch at least).
Andrea
-
To
I recently rewrote the syscall numbering for the x86_64 platform to optimize it
at the cacheline usage level. If somebody wants to overview the numbering and
give feedback or find something better that's welcome. We know we'll break the
kernel API still at least once. I choosed the numbering in
On Wed, Apr 04, 2001 at 09:39:23AM -0700, Kanoj Sarcar wrote:
example, for NUMA, we need to try hard to schedule a thread on the
node that has most of its memory (for no reason other than to decrease
memory latency). Independently, some NUMA machines build in multilevel
caches and local
On Wed, Apr 04, 2001 at 09:50:58AM -0700, Kanoj Sarcar wrote:
I didn't seen anything from Kanoj but I did something myself for the wildfire:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.3aa1/10_numa-sched-1
this is mostly an userspace issue, not
On Wed, Apr 04, 2001 at 10:49:04AM -0700, Kanoj Sarcar wrote:
Imagine that most of the program's memory is on node 1, it was scheduled
on node 2 cpu 8 momentarily (maybe because kswapd ran on node 1, other
higher priority processes took over other cpus on node 1, etc).
Then, your patch
I merged some of SCT's fixes plus I fixed another couple of bugs and then I
boosted the code to run faster. There's still room for improvements for example
by using a ring of iobuf to walk pagetables and lock down pages for the next
atomic I/O chunk while the I/O of the previous iobuf is in
On Fri, Apr 06, 2001 at 06:34:40PM +0200, Andrea Arcangeli wrote:
2.4.3aa3 with rawio-1:
root@alpha:/home/andrea time ./rawio-bench
Opening /dev/raw1
Allocating 50MB of memory
Reading from /dev/raw1
Writing data to /dev/raw1
real0m5.208s
user0m0.001s
sys 0m1.162s
root
On Fri, Apr 06, 2001 at 07:02:32PM +0200, Andi Kleen wrote:
On Fri, Apr 06, 2001 at 07:07:01PM +0200, Andrea Arcangeli wrote:
However we can probably stay with the 512k atomic I/O otherwise the iobuf
structure will grow again of an order of 2. With 512k of atomic I/O the kiovec
structure
On Sun, Apr 08, 2001 at 11:35:36PM +0200, Manfred Spraul wrote:
I've attached a new patch:
* cpu_is_idle() moved to linux/pm.h
* function uninlined due to header dependencies
* cpu_is_idle() doesn't call do_softirq directly, instead the caller
returns to schedule()
* cpu_is_idle()
On Mon, Apr 09, 2001 at 05:26:27PM +0200, Manfred Spraul wrote:
The return path to user space checks for pending softirqs. A delay of
And it breaks the loop too if new softirq events become pending again in
background.
1/HZ is only possible if the cpu loops in kernel space without returning
On Mon, Apr 09, 2001 at 09:48:02PM +0400, [EMAIL PROTECTED] wrote:
Hello!
Btw, you don't schedule the ksoftirqd thread if do_softirq() returns
from the 'if(in_interrupt())' check.
ksoftirqd will not be switched to before the first schedule
or ret form syscall, when softirqs will be
On Mon, Apr 09, 2001 at 07:58:23PM +0100, Alan Cox wrote:
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o
depmod: strstr
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre1/kernel/drivers/parport/parport.o
depmod:
On Sun, Mar 25, 2001 at 11:10:14PM +, Pavel Machek wrote:
I've seen similar bugs. If you hook something on schedule_tq and forget
to set current-need_resched, this is exactly what you get.
keventd fixes tq_scheduler case (tq_scheduler is dead).
Andrea
-
To unsubscribe from this list: send
On Tue, Apr 10, 2001 at 01:12:02PM -0700, Rajagopal Ananthanarayanan wrote:
Hi,
It seems BH_Req is set on a buffer_head by submit_bh.
What part of the code unsets this flag during normal
operations? One path seems to be block_flushpage-unmap_buffer
-clear_bit(BH_Req), but IIRC
On Wed, Apr 11, 2001 at 03:31:37PM -0400, Hubertus Franke wrote:
Below is the fix.
correct. Could you also use cpu_curr(cpu) instead of the longer expression?
(for the mainline it's only a beauty issue of course)
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
I wrote the O_DIRECT zerocopy raw I/O support (dma from disk to the userspace
memory through the filesystem). The patch against 2.4.4pre2 + rawio-3 is here:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre2/o_direct-1
Only ext2 is supported at the moment,
On Thu, Apr 12, 2001 at 07:17:26PM -0400, Greg Louis wrote:
On 20010412 (Thu) at 1726:11 +0100, Alan Cox wrote:
2.4.3-ac5
o Fix rwsem compile problem (me)
No such luck, I fear, at least not with egcs-2.91.66:
/usr/src/linux-2.4.3ac5/include/asm/rwsem.h:26:
On Fri, Apr 13, 2001 at 08:48:05AM -0500, Bob McElrath wrote:
Alan Cox [[EMAIL PROTECTED]] wrote:
(But since the X server shouldn't have the ability to corrupt the
kernel's process list, there has to be a problem in the kernel
somewhere)
The X server has enough priviledge to
On Tue, Apr 17, 2001 at 05:59:13PM +0100, David Howells wrote:
Andrea,
How did you generate the 00_rwsem-generic-1 patch? Against what did you diff?
2.4.4pre3 from kernel.org.
You seem to have removed all the optimised i386 rwsem stuff... Did it not work
for you?
As said the design of
On Tue, Apr 17, 2001 at 08:18:57PM +0100, D . W . Howells wrote:
Andrea,
As said the design of the framework to plugin per-arch rwsem implementation
isn't flexible enough and the generic spinlocks are as well broken, try to
use them if you can (yes I tried that for the alpha, it was
601 - 700 of 3668 matches
Mail list logo
