Hey folks,
Just a quick reminder: don't feed the troll. He's very hungry.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
Hey folks,
Just a quick reminder: don't feed the troll. He's very hungry.
-ben
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On Sat, 19 May 2001, Alexander Viro wrote:
> On Sat, 19 May 2001, Ben LaHaise wrote:
>
> > It's not done yet, but similar techniques would be applied. I envision
> > that a raid device would support operations such as
> > open("/dev/md0/slot=5,hot-add=/dev
On Sat, 19 May 2001, Andrew Clausen wrote:
> (1) these issues are independent. The partition parsing could
> be done in user space, today, by blkpg, if I read the code correctly
> ;-) (there's an ioctl for [un]registering partitions) Never
> tried it though ;-)
I tried to imply that through
Hey folks,
The work-in-progress patch for-demonstration-purposes-only below consists
of 3 major components, and is meant to start discussion about the future
direction of device naming and its interaction block layer. The main
motivations here are the wasting of minor numbers for partitions,
Hey folks,
The work-in-progress patch for-demonstration-purposes-only below consists
of 3 major components, and is meant to start discussion about the future
direction of device naming and its interaction block layer. The main
motivations here are the wasting of minor numbers for partitions,
On Sat, 19 May 2001, Andrew Clausen wrote:
(1) these issues are independent. The partition parsing could
be done in user space, today, by blkpg, if I read the code correctly
;-) (there's an ioctl for [un]registering partitions) Never
tried it though ;-)
I tried to imply that through the
On Sat, 19 May 2001, Alexander Viro wrote:
On Sat, 19 May 2001, Ben LaHaise wrote:
It's not done yet, but similar techniques would be applied. I envision
that a raid device would support operations such as
open(/dev/md0/slot=5,hot-add=/dev/sda)
Think for a moment and you'll see why
Hey folks,
The patch below consists of 3 seperate fixes for helping remove the
deadlocks present in current kernels with respect to highmem systems.
Each fix is to a seperate file, so please accept/reject as such.
The first patch adding __GFP_FAIL to GFP_BUFFER is needed to fix a
livelock
Hey folks,
The patch below consists of 3 seperate fixes for helping remove the
deadlocks present in current kernels with respect to highmem systems.
Each fix is to a seperate file, so please accept/reject as such.
The first patch adding __GFP_FAIL to GFP_BUFFER is needed to fix a
livelock
On Mon, 7 May 2001, Manfred Spraul wrote:
> The main problem is that map_user_kiobuf() locks pages into memory.
> It's a bad idea for pipes. Either we must severely limit the maximum
> amount of data in the direct-copy buffers, or we must add a swap file
> based backing store. If I understand
Manfred Spraul wrote:
>
> I'm now running with the patch for several hours, no problems.
>
> bw_pipe transfer rate has nearly doubled and the number of context
> switches for one bw_pipe run is down from 71500 to 5500.
>
> Please test it.
Any particular reason for not using davem's single
Manfred Spraul wrote:
I'm now running with the patch for several hours, no problems.
bw_pipe transfer rate has nearly doubled and the number of context
switches for one bw_pipe run is down from 71500 to 5500.
Please test it.
Any particular reason for not using davem's single copy
On Mon, 7 May 2001, Manfred Spraul wrote:
The main problem is that map_user_kiobuf() locks pages into memory.
It's a bad idea for pipes. Either we must severely limit the maximum
amount of data in the direct-copy buffers, or we must add a swap file
based backing store. If I understand the
On Sun, 8 Apr 2001, Linus Torvalds wrote:
>
> The "down_writer_failed()" case was wrong:
Which is exactly the same problem in the original code. How about the
following patch against the original code? I hadn't sent it yet as the
test code isn't finished (hence, it's untested), but given that
On Sun, 8 Apr 2001, Linus Torvalds wrote:
The "down_writer_failed()" case was wrong:
Which is exactly the same problem in the original code. How about the
following patch against the original code? I hadn't sent it yet as the
test code isn't finished (hence, it's untested), but given that
On Thu, 5 Apr 2001 [EMAIL PROTECTED] wrote:
> "Albert D. Cahalan" wrote:
> >
> > > I'm running the 2.4.3 kernel and my system always (!) crashes when I try
> > > to generate the "Linux kernel poster" from lgp.linuxcare.com.au. After
> > > working for one hour, the kernel printed this message:
>
On Thu, 5 Apr 2001 [EMAIL PROTECTED] wrote:
"Albert D. Cahalan" wrote:
I'm running the 2.4.3 kernel and my system always (!) crashes when I try
to generate the "Linux kernel poster" from lgp.linuxcare.com.au. After
working for one hour, the kernel printed this message:
I'd guess
On Thu, 1 Mar 2001, Stephen C. Tweedie wrote:
> Yep. There shouldn't be any problem increasing the 64KB size, it's
> only the lack of accounting for the pinned memory which stopped me
> increasing it by default.
Actually, how about making it a sysctl? That's probably the most
reasonable
Hello all,
On Thu, 1 Mar 2001, Stephen C. Tweedie wrote:
> Raw IO is always synchronous: it gets flushed to disk before the write
> returns. You don't get any write-behind with raw IO, so the smaller
> the blocksize you write in, the slower things get.
More importantly, the mainstream raw io
Hello all,
On Thu, 1 Mar 2001, Stephen C. Tweedie wrote:
Raw IO is always synchronous: it gets flushed to disk before the write
returns. You don't get any write-behind with raw IO, so the smaller
the blocksize you write in, the slower things get.
More importantly, the mainstream raw io
On Thu, 1 Mar 2001, Stephen C. Tweedie wrote:
Yep. There shouldn't be any problem increasing the 64KB size, it's
only the lack of accounting for the pinned memory which stopped me
increasing it by default.
Actually, how about making it a sysctl? That's probably the most
reasonable approach
On Tue, 27 Feb 2001, Russell C. Hay wrote:
> I'm not really sure who to send this too. Unfortunately, I don't really have
> much information on this bug, and I will provide more when I'm around the box
> in question. I have linux 2.2.16 running fine on the box. I am currently
> trying to
On Tue, 27 Feb 2001, Russell C. Hay wrote:
I'm not really sure who to send this too. Unfortunately, I don't really have
much information on this bug, and I will provide more when I'm around the box
in question. I have linux 2.2.16 running fine on the box. I am currently
trying to upgrade
On Tue, 20 Feb 2001, Tom Rini wrote:
> Er, say that again? Right now, for bootp if you specify "sa=xxx.xxx.xxx.xxx"
> Linux uses that as the host for the NFS server (which does have the side
> effect of if TFTP server != NFS server, you don't boot). Are you saying
> your patch takes
On Tue, 20 Feb 2001, Tom Rini wrote:
Er, say that again? Right now, for bootp if you specify "sa=xxx.xxx.xxx.xxx"
Linux uses that as the host for the NFS server (which does have the side
effect of if TFTP server != NFS server, you don't boot). Are you saying
your patch takes
On Mon, 19 Feb 2001, Brian J. Watson wrote:
> Here is an x86 implementation of down_read_trylock() and down_write_trylock()
> for read/write semaphores. As with down_trylock() for exclusive semaphores, they
> don't block if they fail to get the lock. They just return 1, as opposed to 0 in
> the
Hello,
Here's a handy little patch that makes the kernel parse out the ip
address of the nfs server from the bootp root path. Otherwise it's
impossible to boot the kernel without command line options on diskless
workstations (I hate RPL).
-ben
diff -ur
Hello,
Here's a handy little patch that makes the kernel parse out the ip
address of the nfs server from the bootp root path. Otherwise it's
impossible to boot the kernel without command line options on diskless
workstations (I hate RPL).
-ben
diff -ur
On Mon, 19 Feb 2001, Brian J. Watson wrote:
Here is an x86 implementation of down_read_trylock() and down_write_trylock()
for read/write semaphores. As with down_trylock() for exclusive semaphores, they
don't block if they fail to get the lock. They just return 1, as opposed to 0 in
the
On Fri, 16 Feb 2001, Linus Torvalds wrote:
> This is, actually, a problem that I suspect ends up being _very_ similar
> to the zap_page_range() case. zap_page_range() needs to make sure that
> everything has been updated by the time the page is actually free'd. While
> filemap_sync() needs to
On Fri, 16 Feb 2001, Manfred Spraul wrote:
> That leaves msync() - it currently does a flush_tlb_page() for every
> single dirty page.
> Is it possible to integrate that into the mmu gather code?
>
> tlb_transfer_dirty() in addition to tlb_clear_page()?
Actually, in the filemap_sync case, the
On Fri, 16 Feb 2001, Linus Torvalds wrote:
> How do you expect to ever see this in practice? Sounds basically
> impossible to test for this hardware race. The obvious "try to dirty as
> fast as possible on one CPU while doing an atomic get-and-clear on the
> other" thing is not valid - it's in
On Fri, 16 Feb 2001, Jamie Lokier wrote:
> It should be fast on known CPUs, correct on unknown ones, and much
> simpler than "gather" code which may be completely unnecessary and
> rather difficult to test.
>
> If anyone reports the message, _then_ we think about the problem some more.
>
> Ben,
On Fri, 16 Feb 2001, Jamie Lokier wrote:
It should be fast on known CPUs, correct on unknown ones, and much
simpler than "gather" code which may be completely unnecessary and
rather difficult to test.
If anyone reports the message, _then_ we think about the problem some more.
Ben, fancy
On Fri, 16 Feb 2001, Linus Torvalds wrote:
How do you expect to ever see this in practice? Sounds basically
impossible to test for this hardware race. The obvious "try to dirty as
fast as possible on one CPU while doing an atomic get-and-clear on the
other" thing is not valid - it's in fact
On Fri, 16 Feb 2001, Manfred Spraul wrote:
That leaves msync() - it currently does a flush_tlb_page() for every
single dirty page.
Is it possible to integrate that into the mmu gather code?
tlb_transfer_dirty() in addition to tlb_clear_page()?
Actually, in the filemap_sync case, the
On Fri, 16 Feb 2001, Linus Torvalds wrote:
This is, actually, a problem that I suspect ends up being _very_ similar
to the zap_page_range() case. zap_page_range() needs to make sure that
everything has been updated by the time the page is actually free'd. While
filemap_sync() needs to make
On Thu, 15 Feb 2001, Kanoj Sarcar wrote:
> No. All architectures do not have this problem. For example, if the
> Linux "dirty" (not the pte dirty) bit is managed by software, a fault
> will actually be taken when processor 2 tries to do the write. The fault
> is solely to make sure that the
On Thu, 15 Feb 2001, Kanoj Sarcar wrote:
No. All architectures do not have this problem. For example, if the
Linux "dirty" (not the pte dirty) bit is managed by software, a fault
will actually be taken when processor 2 tries to do the write. The fault
is solely to make sure that the Linux
On Tue, 6 Feb 2001, Linus Torvalds wrote:
> There are currently no other alternatives in user space. You'd have to
> create whole new interfaces for aio_read/write, and ways for the kernel to
> inform user space that "now you can re-try submitting your IO".
>
> Could be done. But that's a big
On Thu, 8 Feb 2001, Pavel Machek wrote:
> Hi!
>
> > > Its arguing against making a smart application block on the disk while its
> > > able to use the CPU for other work.
> >
> > There are currently no other alternatives in user space. You'd have to
> > create whole new interfaces for
On Thu, 8 Feb 2001, Pavel Machek wrote:
Hi!
Its arguing against making a smart application block on the disk while its
able to use the CPU for other work.
There are currently no other alternatives in user space. You'd have to
create whole new interfaces for aio_read/write, and ways
On Tue, 6 Feb 2001, Linus Torvalds wrote:
There are currently no other alternatives in user space. You'd have to
create whole new interfaces for aio_read/write, and ways for the kernel to
inform user space that "now you can re-try submitting your IO".
Could be done. But that's a big thing.
On Tue, 6 Feb 2001, Ingo Molnar wrote:
>
> On Tue, 6 Feb 2001, Ben LaHaise wrote:
>
> > This small correction is the crux of the problem: if it blocks, it
> > takes away from the ability of the process to continue doing useful
> > work. If it returns -EAGAI
On Tue, 6 Feb 2001, Ingo Molnar wrote:
>
> On Tue, 6 Feb 2001, Ben LaHaise wrote:
>
> > > > You mentioned non-spindle base io devices in your last message. Take
> > > > something like a big RAM disk. Now compare kiobuf base io to buffer
> > > &
On Tue, 6 Feb 2001, Linus Torvalds wrote:
>
>
> On Tue, 6 Feb 2001, Ben LaHaise wrote:
> >
> > s/impossible/unpleasant/. ll_rw_blk blocks; it should be possible to have
> > a non blocking variant that does all of the setup in the caller's context.
> > Yes, I kno
On Tue, 6 Feb 2001, Ingo Molnar wrote:
>
> On Tue, 6 Feb 2001, Ben LaHaise wrote:
>
> > - reduce the overhead in submitting block ios, especially for
> > large ios. Look at the %CPU usages differences between 512 byte
> > blocks and 4KB blocks, this c
On Tue, 6 Feb 2001, Ingo Molnar wrote:
> If you are merging based on (device, offset) values, then that's lowlevel
> - and this is what we have been doing for years.
>
> If you are merging based on (inode, offset), then it has flaws like not
> being able to merge through a loopback or stacked
On Tue, 6 Feb 2001, Ingo Molnar wrote:
> - higher levels do not have the kind of state to eg. merge requests done
> by different users. The only chance for merging is often the lowest
> level, where we already know what disk, which sector.
That's what a readaround buffer is for, and I
On Tue, 6 Feb 2001, Jens Axboe wrote:
> Stephen already covered this point, the merging is not a problem
> to deal with for read-ahead. The underlying system can easily
I just wanted to make sure that was clear =)
> queue that in nice big chunks. Delayed allocation makes it
> easier to to
On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:
> It's worth noting that it *is* defined unambiguously in the standards:
> fsync waits until all the data is hard on disk. Linux will obey that
> if it possibly can: only in cases where the hardware is actively lying
> about when the data has hit
Hey folks,
On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:
> The whole point of the post was that it is merging, not splitting,
> which is troublesome. How are you going to merge requests without
> having chains of scatter-gather entities each with their own
> completion callbacks?
Let me just
Hey folks,
On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:
The whole point of the post was that it is merging, not splitting,
which is troublesome. How are you going to merge requests without
having chains of scatter-gather entities each with their own
completion callbacks?
Let me just
On Tue, 6 Feb 2001, Jens Axboe wrote:
Stephen already covered this point, the merging is not a problem
to deal with for read-ahead. The underlying system can easily
I just wanted to make sure that was clear =)
queue that in nice big chunks. Delayed allocation makes it
easier to to flush
On Tue, 6 Feb 2001, Ingo Molnar wrote:
- higher levels do not have the kind of state to eg. merge requests done
by different users. The only chance for merging is often the lowest
level, where we already know what disk, which sector.
That's what a readaround buffer is for, and I suspect
On Tue, 6 Feb 2001, Ingo Molnar wrote:
If you are merging based on (device, offset) values, then that's lowlevel
- and this is what we have been doing for years.
If you are merging based on (inode, offset), then it has flaws like not
being able to merge through a loopback or stacked
On Tue, 6 Feb 2001, Ingo Molnar wrote:
On Tue, 6 Feb 2001, Ben LaHaise wrote:
- reduce the overhead in submitting block ios, especially for
large ios. Look at the %CPU usages differences between 512 byte
blocks and 4KB blocks, this can be better.
my system is already
On Tue, 6 Feb 2001, Linus Torvalds wrote:
On Tue, 6 Feb 2001, Ben LaHaise wrote:
s/impossible/unpleasant/. ll_rw_blk blocks; it should be possible to have
a non blocking variant that does all of the setup in the caller's context.
Yes, I know that we can do it with a kernel thread
On Tue, 6 Feb 2001, Ingo Molnar wrote:
On Tue, 6 Feb 2001, Ben LaHaise wrote:
You mentioned non-spindle base io devices in your last message. Take
something like a big RAM disk. Now compare kiobuf base io to buffer
head based io. Tell me which one is going to perform better
On Tue, 6 Feb 2001, Ingo Molnar wrote:
On Tue, 6 Feb 2001, Ben LaHaise wrote:
This small correction is the crux of the problem: if it blocks, it
takes away from the ability of the process to continue doing useful
work. If it returns -EAGAIN, then that's okay, the io
On Tue, 30 Jan 2001 [EMAIL PROTECTED] wrote:
>
> Comments, suggestions, advise, feedback solicited !
>
> If this seems like something that might (after some refinements) be a
> useful abstraction to have, then I need some help in straightening out the
> design. I am not very satisfied with it in
On Tue, 30 Jan 2001 [EMAIL PROTECTED] wrote:
Comments, suggestions, advise, feedback solicited !
If this seems like something that might (after some refinements) be a
useful abstraction to have, then I need some help in straightening out the
design. I am not very satisfied with it in its
On Thu, 19 Oct 2000, Linus Torvalds wrote:
> I think you overlooked the fact that SHM mappings use the page cache, and
> it's ok if such pages are dirty and writable - they will get written out
> by the shm_swap() logic once there are no mappings active any more.
>
> I like the test per
On Thu, 19 Oct 2000, Linus Torvalds wrote:
I think you overlooked the fact that SHM mappings use the page cache, and
it's ok if such pages are dirty and writable - they will get written out
by the shm_swap() logic once there are no mappings active any more.
I like the test per se,
Hey folks
Below is take two of the patch making pte_clear use atomic xchg in an
effort to avoid the loss of dirty bits. PAE no longer uses cmpxchg8 for
updates; set_pte is two ordered long writes with a barrier. The use of
long long for ptes is also removed; gcc should generate better code
Hey folks
Below is take two of the patch making pte_clear use atomic xchg in an
effort to avoid the loss of dirty bits. PAE no longer uses cmpxchg8 for
updates; set_pte is two ordered long writes with a barrier. The use of
long long for ptes is also removed; gcc should generate better code
> According to sct (who's sitting next to me in my hotel room at ALS) Ben
> LaHaise has a bugfix for this, but it hasn't been merged.
Here's an updated version of the patch that doesn't do the funky RISC like
dirty bit updates. It doesn't incur the additional overhead of page
faults on dir
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> it works fine then. Kernel compiles in 68 seconds as it should. Shall I
> keep incrementing mem= to see what happens next...
I suspect fixing the mtrrs on the machine will fix this problem, as a
38-40 times slowdown on a machine that isn't swapping
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
it works fine then. Kernel compiles in 68 seconds as it should. Shall I
keep incrementing mem= to see what happens next...
I suspect fixing the mtrrs on the machine will fix this problem, as a
38-40 times slowdown on a machine that isn't swapping is
in my hotel room at ALS) Ben
LaHaise has a bugfix for this, but it hasn't been merged.
Here's an updated version of the patch that doesn't do the funky RISC like
dirty bit updates. It doesn't incur the additional overhead of page
faults on dirty, which actually happens a lot on SHM attaches
(during
71 matches
Mail list logo
