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 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, 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 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, f
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 fa
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 fl
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 mak
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 v2.4.1-ac18/fs/nfs/nfsroo
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 s
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 "rp=xxx.xxx
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 upgra
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 c
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 approa
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,
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 i
> 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 overh
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 now.
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
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 e
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 dis
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 suspec
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 fil
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, 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,
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, 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
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/wr
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 thi
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, and
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 t
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=/de
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
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
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 caused
36 matches
Mail list logo
