Ok, how about this approach? It only works for the case where we do not
have the kind of multiple stuff that drivers/net has, but hey, we don't
actually need to handle all the cases right now.
We can leave that for the future, as the configuration process is likely
to change anyway during
Ok, test10-final is out there now. This has no _known_ bugs that I
consider show-stoppers, for what it's worth.
And when I don't know of a bug, it doesn't exist. Let us rejoice. In
traditional kernel naming tradition, this kernel hereby gets anointed as
one of the "greased weasel" kernel
On Tue, 31 Oct 2000, Rik van Riel wrote:
On Tue, 31 Oct 2000, Linus Torvalds wrote:
Ok, test10-final is out there now. This has no _known_ bugs that
I consider show-stoppers, for what it's worth.
And when I don't know of a bug, it doesn't exist. Let us
rejoice. In traditional
On Tue, 31 Oct 2000, Russell King wrote:
Linus Torvalds writes:
On Wed, 1 Nov 2000, Keith Owens wrote:
LINK_FIRST is processed in the order it is specified, so a.o will be
linked before z.o when both are present. See the patch.
So why don't you do the same thing for obj-y
On Tue, 31 Oct 2000, Miles Lane wrote:
Were there no changes between test10-pre7 and test10?
I notice you didn't send out a Changelist.
The Changelists help me focus my testing.
Sorry. Here it is..
Linus
-
- final:
- Jeff Garzik: ISA network driver cleanup,
On Thu, 2 Nov 2000, Thomas Sailer wrote:
The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff)
specifies that a select _with the sounddriver's filedescriptor
set in the read mask_ should start the recording.
So fix the stupid API.
The above is just idiocy.
In article [EMAIL PROTECTED],
Andrew Morton [EMAIL PROTECTED] wrote:
neither flock() nor fcntl() serialisation are effective
on linux 2.2 or linux 2.4. This is because the file
locking code still wakes up _all_ waiters. In my testing
with fcntl serialisation I have seen a single Apache
On Sat, 4 Nov 2000, Jeff Garzik wrote:
So fix the stupid API.
The above is just idiocy.
We're pretty much stuck with the API, until we look at merging ALSA in
2.5.x. Broken API or not, OSS is a mature API, and there are
spec-correct apps that depend on this behavior.
Considering
On Sat, 4 Nov 2000, Alan Cox wrote:
Even 2.2.x can be fixed to do the wake-one for accept(), if required.
Do we really want to retrofit wake_one to 2.2. I know Im not terribly keen to
try and backport all the mechanism. I think for 2.2 using the semaphore is a
good approach. Its a
On Tue, 7 Nov 2000, Andrew Morton wrote:
Alan Cox wrote:
Even 2.2.x can be fixed to do the wake-one for accept(), if required.
Do we really want to retrofit wake_one to 2.2. I know Im not terribly keen to
try and backport all the mechanism. I think for 2.2 using the semaphore is
Mostly driver updates.
With a few notable exceptions: two rather subtle MM race conditions that
happened with SMP and highmem respectively. And the FXCSR and file locking
that was already discussed on the list.
Linus
-
- pre1:
- me: make PCMCIA work even in the
On Tue, 7 Nov 2000, Gary E. Miller wrote:
I see this patch did not make it into test11-pre1. Without it
raid1 and SMP do not work together. Please consider for test11-pre2.
You must have a different test11-pre1 than the one I have.
It's already there in -pre1, as far as I can see.
On Wed, 8 Nov 2000, Michael Rothwell wrote:
Linus Torvalds wrote:
Also, I've never seen much in the form of explanation, and at least the
last patch I saw just the first screenful was so off-putting that I just
went "Ok, I have real bugs to fix, I don't need this crap".
On Wed, 8 Nov 2000, Michael Rothwell wrote:
Like what? I'm not sure what you're saying here. It seems that the pople
writing the IrDA code have gotten no feedback from you as to why their
patch is never accepted -- could you clarify?
Just to clarify.
The ONLY message from the IrDA people
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] wrote:
Be careful with the intel patches. The ones I've seen so far tried to call the
cpu 'if86' breaking several tools that do cpu model checking off uname. They
didnt fix the 2GHz CPU limit, they use 'rep nop' in the locks which is
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] wrote:
rep;nop is a magic instruction on the PIV and possibly some PIII series CPUs
[not sure]. As far as I can make out it naps momentarily or until bus
activity thus saving power on spinlocks.
From what I've heard, the reason Intel
On Wed, 8 Nov 2000, Alan Cox wrote:
unless that CPU is also SMP-capable). It's documented by intel these
days, and it works on all CPU's I've ever heard of, and it even makes
sense to me (*).
Do the intel docs guarantee it works on i486 and higher, if so SMP athlon
will be the only
On Thu, 9 Nov 2000, Jens Axboe wrote:
The second is more elegant in that it side steps the problem by
giving rd.c a make_request function instead of using the default
_make_request. This means that io_request_lock is simply never
claimed my rd.
And this solution is much
As to the real reason for stalls on /proc/pid/stat, I bet it has nothing
to do with IO except indirectly (the IO is necessary to trigger the
problem, but the _reason_ for the problem lies elsewhere).
And it has everything to do with the fact that the way Linux semaphores
are implemented, a
In article [EMAIL PROTECTED], David Ford [EMAIL PROTECTED] wrote:
The oddity is that kdb shows the machine to lock up on the popf in
pci_conf_write_word()+0x2c. I never did get around to digging up this
routine and looking at the code, but I suspect this is a final return
from the routine.
Nothing stands out as affecting most people here. Security fix for /proc,
and various cleanups. Alpha and sparc fixes. If you use RAID or ramdisk,
upgrade.
Linus
-
- pre2:
- Stephen Rothwell: directory notify could return with the lock held
- Richard Henderson:
In article [EMAIL PROTECTED],
Mike Galbraith [EMAIL PROTECTED] wrote:
(This schenario, btw, is much harder to trigger on SMP than on UP. And
it's completely separate from the issue of simple disk bandwidth issues
which can obviously cause no end of stalls on anything that needs the
disk,
In article [EMAIL PROTECTED],
David Mansfield [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
...
And it has everything to do with the fact that the way Linux semaphores
are implemented, a non-blocking process has a HUGE advantage over a
blocking one. Linux kernel semaphores are extreme
In article [EMAIL PROTECTED],
Jeff Garzik [EMAIL PROTECTED] wrote:
sendfile(2) fails with -EINVAL every time I try to read from a device
file.
This sounds like a bug... is it? (the man page doesn't mention such a
restriction)
sendfile() on purpose only works on things that use the page cache.
On Sun, 12 Nov 2000, Dag Brattli wrote:
(resending in case it got lost, didn't show up on linux-kernel)
Didn't get lost, but I think the linux-kernel size filter killed it from
the kernel list.
Everything applied. Thanks,
Linus
-
To unsubscribe from this list: send the
On Sat, 11 Nov 2000, Ying Chen/Almaden/IBM wrote:
This patch includes two sets of things against test10:
First, there are several places where schedule() is called after
wakeup_bdflush(1) is called. This is completely unnecessary
Fair enough.
Second, (I have posted this to the kernel
Ok, thanks to the work of Jean, everything seems to be applied now.
I'll make a test3 one of these days (probably tomorrow), please verify
that everything looks happy.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Fri, 10 Nov 2000, Alexander Viro wrote:
diff -urN rc11-2/include/asm-i386/processor.h
rc11-2-show_task/include/asm-i386/processor.h
--- rc11-2/include/asm-i386/processor.h Fri Nov 10 09:14:04 2000
+++ rc11-2-show_task/include/asm-i386/processor.h Fri Nov 10 16:08:15 2000
@@
Drivers, drivers, drivers. IrDA and ISDN. PPC.
The most interesting part is probably the exclusive wait-queue patch.
David Miller noticed that exclusivity doesn't nest correctly the way we
used to do it: being on multiple wait-queues would potentially cause lost
wake-up events if a
More drivers.
The x86 capabilities cleanup is here.
Linus
- pre5:
- Rasmus Andersen: add proper "linux/init.h" for sound drivers
- David Miller: sparc64 and networking updates
- David Trcka: MOXA numbering starts from 0, not 1.
- Jeff Garzik: sysctl.h
On Wed, 15 Nov 2000, Dan Aloni wrote:
summery: dev_3c501.name shouldn't be NULL, or we get oops
Note that these days "name" is not a pointer at all, but an array, and as
such cannot be NULL any more. Not initializing it will just cause it to be
empty (ie is the same as initializing it to
In article [EMAIL PROTECTED],
Dan Aloni [EMAIL PROTECTED] wrote:
On Tue, 14 Nov 2000, Jeff Garzik wrote:
Dan Aloni wrote:
reason: Correct me if I'm wrong, but 3c501.c:init_module() calls
net_init.c:register_netdev(dev_3c501), which calls strchr(),
{and might also,which might}
In article [EMAIL PROTECTED],
After some trickery with some special hardware feature (storage
keys) I found out that empty_bad_pmd_table and empty_bad_pte_table have
been put to the page table quicklists multiple(!) times.
This is definitely bad, and means that something else really bad
On Thu, 16 Nov 2000, Andries Brouwer wrote:
Has there been a kernel version that could read these?
It looks like it proclaims blocksize 512 and uses blocksize 2048 or so.
The (de_len == 0) check in do_isofs_readdir() seems to imply that the
blocksize is always 2048. So at the very least
Does this patch fix it for you?
Warning: TOTALLY UNTESTED!!! Please test carefully.
Also, I'd be interested to know whether somebody really knows if the zero
length handling is correct. Should we really round up to 2048, or should
we perhaps round up only to the next bufsize?
On Wed, 15 Nov 2000, Linus Torvalds wrote:
Does this patch fix it for you?
Warning: TOTALLY UNTESTED!!! Please test carefully.
Ok, I tested it with the broken image.
It looks like "readdir()" is ok now (but not really knowing what the right
output should be I cannot
On Thu, 16 Nov 2000 [EMAIL PROTECTED] wrote:
If noone else does, I suppose I can.
Thanks.
( .. gets ENOENT ..
and that is not because it only is a partial image?)
I don't think so, but I obviously have no way of actually confirming my
suspicion.
If the stat information was wrong due
On Thu, 16 Nov 2000, Jean-Marc Saffroy wrote:
As you see, it looks like the rmdir fails simply because the dir name ends
with a dot !! This is confirmed by sys_rmdir in fs/namei.c, around line
1384 :
switch(nd.last_type) {
case LAST_DOTDOT:
On Thu, 16 Nov 2000 [EMAIL PROTECTED] wrote:
Ok, the BUG() hit in get_pmd_slow:
pmd_t *
get_pmd_slow(pgd_t *pgd, unsigned long offset)
{
pmd_t *pmd;
int i;
pmd = (pmd_t *) __get_free_pages(GFP_KERNEL,2);
You really need 4 pages?
There's no way to reliably
On Thu, 16 Nov 2000, Andrea Arcangeli wrote:
If they absolutely needs 4 pages for pmd pagetables due hardware constraints
I'd recommend to use _four_ hardware pages for each softpage, not two.
Yes.
However, it definitely is an issue of making trade-offs. Most 64-bit MMU
models tend to
On Thu, 16 Nov 2000, Alexander Viro wrote:
On Thu, 16 Nov 2000, Alan Cox wrote:
The only disadvantage to this scheme is the added cost of a kernel
thread over a kernel timer. I think this is an ok cost, because this
is a low-impact thread that sleeps a lot..
8K of memory,
On Thu, 16 Nov 2000, Dan Aloni wrote:
Makes procfs use an atomic use count for dir entries, to avoid using
the Big kernel lock. Axboe says it looks ok.
There's a race there. Look at what happens if de_put() races with
remove_proc_entry(): we'd do free_proc_entry() twice. Not good.
Leave
The log-file says it all..
Linus
-
- pre6:
- Intel: start to add Pentium IV specific stuff (128-byte cacheline
etc)
- David Miller: search-and-destroy places that forget to mark us
running after removing us from a wait-queue.
- me: NFS client
On Fri, 17 Nov 2000, Russell King wrote:
Alan Cox writes:
From a practical point of view that currently means 'delete Linus tree pcmcia
regardless of what you are doing' since the modules from David Hinds and Linus
pcmcia are not 100% binary compatible for all cases.
However,
On Fri, 17 Nov 2000, Alan Cox wrote:
regardless of what you are doing' since the modules from David Hinds and Linus
pcmcia are not 100% binary compatible for all cases.
However, deleting that code would render a significant number of ARM platforms
without PCMCIA support, which
On Fri, 17 Nov 2000, Alan Cox wrote:
Alan, Russell is talking about CardBus controllers (it's also PCMCIA, in
fact, these days it's the _only_ pcmcia in any machine made less than five
years ago).
I have at least two machines here that are 2 years old but disagree
with you. Once is
On Fri, 17 Nov 2000 [EMAIL PROTECTED] wrote:
Whats the reasoning behind these ifs ?
To catch memory corruption or things running out of control in the kernel.
I was refering to the "if (!order) goto try_again" ifs in alloc_pages, not
the "if (something) BUG()" ifs.
Basically, if you
On Fri, 17 Nov 2000, Jeff Garzik wrote:
2. Even when I specify cs_irq=27, it resorts to polling:
Intel PCIC probe:
Intel i82365sl DF ISA-to-PCMCIA at port 0x8400 ofs 0x00, 2 sockets
host opts [0]: none
host opts [1]: none
On Fri, 17 Nov 2000, Harald Koenig wrote:
this seems to make things much worse: starting with ~90M free memory
"du" again started leaking (or maybe just using memory?) down to ~80M free
memory when the system suddently locked up completely, no console switch
was possible anymore (but
On Fri, 17 Nov 2000, Harald Koenig wrote:
Linus:0.380u 76.850s 1:19.12 97.6%0+0k 0+0io 113pf+0w
Andries: 0.470u 97.220s 1:40.29 97.4%0+0k 0+0io 112pf+0w
The biggest difference is just the system times and the fact that it's
more efficient coding.
BUT: there
On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote:
But now that you did two-thirds of the job I take it you'll
also do the third part? It is again precisely the same stuff.
Are you talking about isofs_lookup_grandparent()?
The code is now dead, and has been for a long time actually (as the VFS
Oh, and sorry - the last patch doesn't contain the (obvious) fixes to the
header files to take some of the calling convention changes into account.
Linus
---
--- v2.4.0-test10/linux/include/linux/iso_fs.h Fri Sep 8 12:52:56 2000
+++ linux/include/linux/iso_fs.hFri
There's a test11-pre7 there now, and I'd really ask people to check out
the isofs changes because slight worry about those is what held me up from
just calling it test11 outright.
It's almost guaranteed to be better than what we had before, but anyway..
Linus
-
To unsubscribe
In article [EMAIL PROTECTED], J Sloan [EMAIL PROTECTED] wrote:
looks like the md fixes broke something -
In file included from /usr/src/linux/include/linux/pagemap.h:17,
from /usr/src/linux/include/linux/locks.h:9,
from
In article [EMAIL PROTECTED],
=?iso-8859-1?q?Markus=20Schoder?= [EMAIL PROTECTED] wrote:
The following small program (linked against glibc 2.1.3) reliably
freezes my system (Athlon Thunderbird CPU) with at least kernels
2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq keys do not work
after
In article [EMAIL PROTECTED],
=?iso-8859-1?q?Markus=20Schoder?= [EMAIL PROTECTED] wrote:
The following small program (linked against glibc 2.1.3) reliably
freezes my system (Athlon Thunderbird CPU) with at least kernels
2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq keys do not work
after
On Sat, 18 Nov 2000, Keith Owens wrote:
On Fri, 17 Nov 2000 17:21:53 -0800 (PST),
Linus Torvalds [EMAIL PROTECTED] wrote:
There's a test11-pre7 there now, and I'd really ask people to check out
the isofs changes because slight worry about those is what held me up from
just calling
In article [EMAIL PROTECTED],
Andrew Morton [EMAIL PROTECTED] wrote:
Also, somewhere on the path from kernel 2.2 to 2.4 the call to
do_notify_parent() was moved inside the tasklist lock. Why was this?
Ehh.. Because that is also what protects our "parent" pointer.
Linus
-
To
On Fri, 17 Nov 2000, Miles Lane wrote:
I haven't seen any announcements of recent test and test-pre releases.
Can you begin sending those again, please?
You can actually get them off kernel.org these days: Peter Anvin set up a
system whereby when I upload a changelog it automatically gets
On Sat, 18 Nov 2000, David Ford wrote:
Linus Torvalds wrote:
[...]
If somebody still has a problem with the in-kernel stuff, speak up.
The kernel's irq detection for the card sockets doesn't work for me. It's the NEC
Versa LX story. The DH code also reports no IRQ found but still
On Sat, 18 Nov 2000, Brian Gerst wrote:
I get Floating Point Exception (core dumped), but I needed to use the
modified program below to keep GCC from optimizing the division away as
a constant. This is on test11-pre5.
I'm starting to suspect that it's really a combination of three
On Sat, 18 Nov 2000, Alan Cox wrote:
Linus Torvalds wrote:
I sure as hell hope this isn't an Athlon issue. Can other people try
the test-program and see if we have a pattern (ie "it happens only on
Athlons", or "Linus is on drugs and it happens for everybody el
In article [EMAIL PROTECTED], Greg KH [EMAIL PROTECTED] wrote:
On Fri, Nov 17, 2000 at 11:25:50PM -0800, Ben Ford wrote:
Here is lspci output from the laptop in question. Is this not UHCI?
Yes it is. Just a bit funny if you think about it, but with Intel and
Via putting the UHCI core into
On Sat, 18 Nov 2000, Markus Schoder wrote:
Your test program is indeed sufficient to trigger the
freeze. Unfortunately the patch does not make a
difference :(
Ok.
This may in fact be an Athlon CPU bug. But before we contact anybody from
AMD, I'd really need to know what the result from
On Sat, 18 Nov 2000, adrian wrote:
On Sat, 18 Nov 2000, Linus Torvalds wrote:
There's almost certainly more than that. I'd love to have a report on my
asm-only version, but even so I suspect it also requires the 3dnow stuff,
I tried all three versions, and no freezes. I forgot
On Sun, 19 Nov 2000, Andrew Morton wrote:
Has anyone tried it on SMP? I get fairly repeatable instances of immortal
`D'-state processes with this patch.
Too bad. I really thought it should be safe to do.
The patch isn't right - it allows `sleepers' to increase without bound.
But it's a
On Sat, 18 Nov 2000, David Ford wrote:
Linus Torvalds wrote:
Can you (you've probably done this before, but anyway) enable DEBUG in
arch/i386/kernel/pci-i386.h? I wonder if the kernel for some strange
reason doesn't find your router, even though "dump_pirq" obvi
On Sun, 19 Nov 2000, Andrew Morton wrote:
I don't see a path where David's patch can cause a lost wakeup in the
way you describe.
Basically, if there are two up() calls, they might end up waking up only
one process, because the same process goes to sleep twice. That's wrong.
It should wake
On Sun, 19 Nov 2000, Rich Baum wrote:
The patch is in the v2.3 directory. You may want to move it to the
v2.4 directory so people can find it easier.
Oops. Thanks. Done.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Tue, 17 Apr 2001, Pavel Machek wrote:
These are tiny cleanups you might like. sizes are "logically"
long.
No. Sizes are not "logical". They are whatever you decide they are, ie
it's purely a complier convention.
At least earlier, size_t was defined as "unsigned int" in user mode, and
[ Cc'd to linux-kernel, to get feedback etc. I've already talked this over
with some people a long time ago, but more people might get interested ]
On Tue, 17 Apr 2001, Mike Kravetz wrote:
In the near future, I should have some time to begin
working on a prototype implementation. One
On Thu, 19 Apr 2001, Alon Ziv wrote:
* the userspace struct was just a signed count and a file handle.
The main reason I wanted to avoid a filehandle is just because it's
another name space that people already use, and that people know what the
semantics are for (ie "open()" is _defined_ to
On Thu, 19 Apr 2001, Abramo Bagnara wrote:
[ Using file descriptors ]
This would also permit:
- to have poll()
- to use mmap() to obtain the userspace area
It would become something very near to sacred Unix dogmas ;-)
No, this is NOT what the UNIX dogmas are all about.
When UNIX says
On Thu, 19 Apr 2001, Alan Cox wrote:
can libraries use fast semaphores behind the back of the user? They might
well want to use the semaphores exactly for things like memory allocator
locking etc. But libc certainly cant use fd's behind peoples backs.
libc is entitled to, and most
On Thu, 19 Apr 2001, Alexander Viro wrote:
Ehh... Non-lazy variant is just read() and write() as down_failed() and
up_wakeup() Lazy... How about
Looks good to me. Anybody want to try this out and test some benchmarks?
There may be problems with large numbers of semaphores, but hopefully
In article 9bn3sr$fer$[EMAIL PROTECTED],
Wichert Akkerman [EMAIL PROTECTED] wrote:
What you can do is what strace does: insert a loop instruction after
the fork or clone call and remove that when the call returns.
You're probably even better off just intercepting the fork, turning it
into a
On 19 Apr 2001, Ulrich Drepper wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
Looks good to me. Anybody want to try this out and test some benchmarks?
I fail to see how this works across processes.
It's up to FS_create() to create whatever shared mapping is needed.
For threads, you
On Thu, 19 Apr 2001, Ingo Oeser wrote:
Are you sure, you can implement SMP-safe, atomic operations (which you need
for all up()/down() in user space) WITHOUT using privileged
instructions on ALL archs Linux supports?
Why do you care?
Sure, there are broken architectures out there. They'd
On Thu, 19 Apr 2001, Ingo Oeser wrote:
On Thu, Apr 19, 2001 at 09:11:56AM -0700, Linus Torvalds wrote:
No, this is NOT what the UNIX dogmas are all about.
When UNIX says "everything is a file", it really means that "everything is
a stream of bytes". Things l
On 19 Apr 2001, Ulrich Drepper wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
I fail to see how this works across processes.
It's up to FS_create() to create whatever shared mapping is needed.
No, the point is that FS_create is *not* the one creating the shared
mapping. The user
On Fri, 20 Apr 2001, Mark Kettenis wrote:
I believe the 2.2.x behaviour was pretty much
useless,
No. 2.2.x is not useless, it is apparently _buggy_ in this regard. Some of
the fixes in the 2.3.x timeframe seem to not have made it into 2.2.x.
Linus
-
To
In article [EMAIL PROTECTED],
Olaf Titz [EMAIL PROTECTED] wrote:
Ehh.. I will bet you $10 USD that if libc allocates the next file
descriptor on the first "malloc()" in user space (in order to use the
semaphores for mm protection), programs _will_ break.
Of course, but this is a result from
On Fri, 20 Apr 2001, Andrea Arcangeli wrote:
While dropping the list_empty check to speed up the fast path I faced the same
complexity of the 2.4.4pre4 lib/rwsem.c and so before reinventing the wheel I
read how the problem was solved in 2.4.4pre4.
I would suggest the following:
- the
On Fri, 20 Apr 2001, Jeremy Fitzhardinge wrote:
This is a fix for a potential deadlock in autofs4's expire routine.
It's wrong.
I don't think we should be able to do a mntput() _either_ inside the
spinlock. The filesystem should not "know" that mntput is safe.
For this reason I don't think
On Fri, 20 Apr 2001, Jeremy Fitzhardinge wrote:
I kept the dget/put out caution and ignorance, but they're clearly
problematic. I'm happy to drop them if holding dcache_lock is enough
to keep the tree stable while I traverse it.
How does this patch look to you people?
It's untested, but
On Fri, 20 Apr 2001, David Howells wrote:
The file should only be used for the 80386 and maybe early 80486's where
CMPXCHG doesn't work properly, everything above that can use the XADD
implementation.
Why are those not using the generic files? The generic code is obviously
more
On Sat, 21 Apr 2001, Russell King wrote:
Erm, spin_lock()? What if up_read or up_write gets called from interrupt
context (is this allowed)?
Currently that is not allowed.
We allow it for regular semaphores, but not for rw-semaphores.
We may some day have to revisit that issue, but I
In article [EMAIL PROTECTED],
Rik van Riel [EMAIL PROTECTED] wrote:
What I _am_ worried about is the fact that we do this to pages with
a really high page age. These things are in active use and cannot
be swapped out any time soon, yet we do claim swap space for it ...
Ehh... And if we didn't
On Sat, 21 Apr 2001, Rik van Riel wrote:
We should _absolutely_ do the swap space reclaiming without looking at
the page count.
page-age != page-count
It's all the same thing.
The page age and count are used to decice when the page actually gets
thrown _out_ of memory. That's a
On Mon, 23 Apr 2001, Jonathan Morton wrote:
There seems to be one more reason, take a look at the function
read_swap_cache_async() in swap_state.c, around line 240:
/*
* Add it to the swap cache and read its contents.
*/
lock_page(new_page);
On Mon, 23 Apr 2001, Ingo Molnar wrote:
you are right - i thought about that issue too and assumed it works like
the pagecache (which first reads the page without hashing it, then tries
to add the result to the pagecache and throws away the page if anyone else
finished it already), but
On 23 Apr 2001, Eric W. Biederman wrote:
ptrace is protected by the big kernel lock, but exec isn't so that
doesn't help. Hmm. ptrace does require that the process be stopped
in all cases
Right. Ptrace definitely cannot access a process at arbitrary times. In
fact, it is very serialized
On Mon, 23 Apr 2001, D.W.Howells wrote:
Linus, you suggested that the generic list handling stuff would be faster (2
unconditional stores) than mine (1 unconditional store and 1 conditional
store and branch to jump round it). You are both right and wrong. The generic
code does two stores
On Tue, 24 Apr 2001, David Howells wrote:
Yes but the struct rwsem_waiter batch would have to be entirely deleted from
the list before any of them are woken, otherwise the waking processes may
destroy their rwsem_waiter blocks before they are dequeued (this destruction
is not guarded by a
On Tue, 24 Apr 2001, Andrea Arcangeli wrote:
Again it's not a performance issue, the +a (sem) is a correctness issue
because the slow path will clobber it.
There must be a performance issue too, otherwise our read up/down fastpaths
are the same. Which clearly they're not.
I
In article [EMAIL PROTECTED],
Christian Ehrhardt [EMAIL PROTECTED] wrote:
1.) If I'm not mistaken switch_to changes current-flags without
atomic operations and without any locks and sys_ptrace changes
child-flags only protected by the big kernel lock.
ptrace only operates on processes that are
[ Alan, I'm lazy and only have 2.2.14 sources on-line. Maybe this has
been fixed already and there's something else going on. Worth a look ]
In article [EMAIL PROTECTED],
Victor Zandy [EMAIL PROTECTED] wrote:
Someone else here traced the process flags of a FP-intensive program
on a machine
On Tue, 24 Apr 2001, Ingo Molnar wrote:
the latest swap-speedup patch can be found at:
Please don't add more of those horrible wait arguments.
Make two different versions of a function instead. It's going to clean up
and simplify the code, and there really isn't any reason to do what you're
On Tue, 24 Apr 2001, Jean Tourrilhes wrote:
I've got a question... I would like where to send my driver
patches...
Probably both me and Alan.
[ General rules follow. Too few people seem to have seen them before ]
Most importantly, when sending patches to me:
- specify clearly that
On Thu, 26 Apr 2001, Mike Galbraith wrote:
2.4.4.pre7.virgin
real11m33.589s
user7m57.790s
sys 0m38.730s
2.4.4.pre7.sillyness
real9m30.336s
user7m55.270s
sys 0m38.510s
Well, I actually like parts of this. The always swap out current mm one
looks rather
701 - 800 of 24431 matches
Mail list logo
