* Re: 2.5.68-mm2
2003-04-23 8:20 2.5.68-mm2 Andrew Morton
@ 2003-04-23 9:59 ` William Lee Irwin III
2003-04-23 16:50 ` 2.5.68-mm2 Robert Love
2003-04-24 9:14 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 12:08 ` 2.5.68-mm2 Ed Tomlinson
` (2 subsequent siblings)
3 siblings, 2 replies; 27+ messages in thread
From: William Lee Irwin III @ 2003-04-23 9:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm, rml
On Wed, Apr 23, 2003 at 01:20:46AM -0700, Andrew Morton wrote:
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.68/2.5.68-mm2.gz
> Will appear sometime at:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.68/2.5.68-mm2/
> . Zillions of new fixes.
> . I got tired of the objrmap code going BUG under stress, so it is now in
> disgrace in the experimental/ directory.
rml and I coordinated to put together a small patch (combining both
our own) for properly locking the static variables in out_of_memory().
There's not any evidence things are going wrong here now, but it at
least addresses the visible lack of locking in out_of_memory().
Applies cleanly to 2.5.68-mm2.
-- wli
diff -urpN mm1-2.5.68-1/mm/oom_kill.c mm1-2.5.68-1A/mm/oom_kill.c
--- mm1-2.5.68-1/mm/oom_kill.c 2003-04-20 00:24:46.000000000 -0700
+++ mm1-2.5.68-1A/mm/oom_kill.c 2003-04-22 21:43:40.000000000 -0700
@@ -208,6 +208,11 @@ static void oom_kill(void)
*/
void out_of_memory(void)
{
+ /*
+ * oom_lock protects out_of_memory()'s static variables.
+ * It's a global lock; this is not performance-critical.
+ */
+ static spinlock_t oom_lock = SPIN_LOCK_UNLOCKED;
static unsigned long first, last, count, lastkill;
unsigned long now, since;
@@ -217,6 +222,7 @@ void out_of_memory(void)
if (nr_swap_pages > 0)
return;
+ spin_lock(&oom_lock);
now = jiffies;
since = now - last;
last = now;
@@ -235,14 +241,14 @@ void out_of_memory(void)
*/
since = now - first;
if (since < HZ)
- return;
+ goto out_unlock;
/*
* If we have gotten only a few failures,
* we're not really oom.
*/
if (++count < 10)
- return;
+ goto out_unlock;
/*
* If we just killed a process, wait a while
@@ -251,15 +257,27 @@ void out_of_memory(void)
*/
since = now - lastkill;
if (since < HZ*5)
- return;
+ goto out_unlock;
/*
* Ok, really out of memory. Kill something.
*/
lastkill = now;
+
+ /* oom_kill() sleeps */
+ spin_unlock(&oom_lock);
oom_kill();
+ spin_lock(&oom_lock);
reset:
- first = now;
+ /*
+ * We dropped the lock above, so check to be sure the variable
+ * first only ever increases to prevent false OOM's.
+ */
+ if (time_after(now, first))
+ first = now;
count = 0;
+
+out_unlock:
+ spin_unlock(&oom_lock);
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: 2.5.68-mm2
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
@ 2003-04-23 16:50 ` Robert Love
2003-04-23 16:57 ` 2.5.68-mm2 Martin J. Bligh
2003-04-24 9:14 ` 2.5.68-mm2 William Lee Irwin III
1 sibling, 1 reply; 27+ messages in thread
From: Robert Love @ 2003-04-23 16:50 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Andrew Morton, linux-kernel, linux-mm
On Wed, 2003-04-23 at 05:59, William Lee Irwin III wrote:
> rml and I coordinated to put together a small patch (combining both
> our own) for properly locking the static variables in out_of_memory().
> There's not any evidence things are going wrong here now, but it at
> least addresses the visible lack of locking in out_of_memory().
Thank you for posting this, wli.
> - first = now;
> + /*
> + * We dropped the lock above, so check to be sure the variable
> + * first only ever increases to prevent false OOM's.
> + */
> + if (time_after(now, first))
> + first = now;
Just thinking... this little bit is actually a bug even on UP sans
kernel preemption, too, since oom_kill() can sleep. If it sleeps, and
another process enters out_of_memory(), 'now' and 'first' will be out of
sync.
So I think this patch is a Good Thing in more ways than the obvious SMP
or kernel preemption issue.
Robert Love
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 16:50 ` 2.5.68-mm2 Robert Love
@ 2003-04-23 16:57 ` Martin J. Bligh
2003-04-23 17:11 ` 2.5.68-mm2 Robert Love
0 siblings, 1 reply; 27+ messages in thread
From: Martin J. Bligh @ 2003-04-23 16:57 UTC (permalink / raw)
To: Robert Love, William Lee Irwin III; +Cc: Andrew Morton, linux-kernel, linux-mm
>> rml and I coordinated to put together a small patch (combining both
>> our own) for properly locking the static variables in out_of_memory().
>> There's not any evidence things are going wrong here now, but it at
>> least addresses the visible lack of locking in out_of_memory().
>
> Thank you for posting this, wli.
>
>> - first = now;
>> + /*
>> + * We dropped the lock above, so check to be sure the variable
>> + * first only ever increases to prevent false OOM's.
>> + */
>> + if (time_after(now, first))
>> + first = now;
>
> Just thinking... this little bit is actually a bug even on UP sans
> kernel preemption, too, since oom_kill() can sleep. If it sleeps, and
> another process enters out_of_memory(), 'now' and 'first' will be out of
> sync.
>
> So I think this patch is a Good Thing in more ways than the obvious SMP
> or kernel preemption issue.
Is this the bug that akpm was seeing, or a different one? The only
information I've seen (indirectly) is that fsx triggers the oops.
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 16:57 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-23 17:11 ` Robert Love
0 siblings, 0 replies; 27+ messages in thread
From: Robert Love @ 2003-04-23 17:11 UTC (permalink / raw)
To: Martin J. Bligh
Cc: William Lee Irwin III, Andrew Morton, linux-kernel, linux-mm
On Wed, 2003-04-23 at 12:57, Martin J. Bligh wrote:
> Is this the bug that akpm was seeing, or a different one? The only
> information I've seen (indirectly) is that fsx triggers the oops.
I cannot see this cause an oops, so no.
Just out-of-sync values resulting in an unexpected OOM or a delayed OOM.
Robert Love
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 16:50 ` 2.5.68-mm2 Robert Love
@ 2003-04-24 9:14 ` William Lee Irwin III
1 sibling, 0 replies; 27+ messages in thread
From: William Lee Irwin III @ 2003-04-24 9:14 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm, rml
On Wed, Apr 23, 2003 at 02:59:26AM -0700, William Lee Irwin III wrote:
> rml and I coordinated to put together a small patch (combining both
> our own) for properly locking the static variables in out_of_memory().
> There's not any evidence things are going wrong here now, but it at
> least addresses the visible lack of locking in out_of_memory().
> Applies cleanly to 2.5.68-mm2.
Improved OOM killer behavior verified on 64GB i386.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 8:20 2.5.68-mm2 Andrew Morton
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
@ 2003-04-23 12:08 ` Ed Tomlinson
2003-04-23 12:37 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 14:25 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
2003-05-01 6:19 ` [BUG] 2.5.68-mm2 and list.h Alexander Hoogerhuis
3 siblings, 2 replies; 27+ messages in thread
From: Ed Tomlinson @ 2003-04-23 12:08 UTC (permalink / raw)
To: Andrew Morton, linux-mm
On April 23, 2003 04:20 am, Andrew Morton wrote:
> . I got tired of the objrmap code going BUG under stress, so it is now in
> disgrace in the experimental/ directory.
As far as I see it there are two problems that objrmap/shpte/pgcl try to solve.
One is low memory pte useage, the second being to reduce the rmap fork overhead.
objrmap helps in both cases but has problem with truncate and intoduces a O(n^2)
search into the the vm.
shpte helps a lot with the first problem, and does not seem to do much for the
second. If I remember correctly it could also be a config option.
pgcl should help with both to some extent but is not ready for prime time - yet.
>From comments recently made on lkml I believe that the first problem is probably
more pressing. What problems need to be resolved with each patch?
Ed Tomlinson
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 12:08 ` 2.5.68-mm2 Ed Tomlinson
@ 2003-04-23 12:37 ` William Lee Irwin III
2003-04-23 14:25 ` 2.5.68-mm2 Martin J. Bligh
1 sibling, 0 replies; 27+ messages in thread
From: William Lee Irwin III @ 2003-04-23 12:37 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Andrew Morton, linux-mm
On April 23, 2003 04:20 am, Andrew Morton wrote:
>> . I got tired of the objrmap code going BUG under stress, so it is now in
>> disgrace in the experimental/ directory.
On Wed, Apr 23, 2003 at 08:08:25AM -0400, Ed Tomlinson wrote:
> As far as I see it there are two problems that objrmap/shpte/pgcl
> try to solve. One is low memory pte useage, the second being to
> reduce the rmap fork overhead.
pgcl has no relation to time or space overhead for pagetables or
pte_chains. Its use for highmem is mostly for shrinking mem_map[].
On Wed, Apr 23, 2003 at 08:08:25AM -0400, Ed Tomlinson wrote:
> objrmap helps in both cases but has problem with truncate and
> intoduces a O(n^2) search into the the vm.
> shpte helps a lot with the first problem, and does not seem to do
> much for the second. If I remember correctly it could also be a
> config option.
> pgcl should help with both to some extent but is not ready for prime
> time - yet.
> From comments recently made on lkml I believe that the first problem
> is probably more pressing. What problems need to be resolved with
> each patch?
I don't see that pgcl should help with either; its benefits are
increasing physical memory contiguity (good for io), larger fs
blocksize support (feature), and reduction in the number of objects
manipulated by the VM (mem_map[] size). There are no results either
way showing that it improves or degrades page replacement (and if it
improved it would be only by a linear factor, which does not repair
issues involving quadratic algorithms).
I'd love to claim as many benefits as possible for page clustering,
but these are so far outside its scope I'd like to avoid promising
things it's unlikely to deliver.
IMHO shpte, enhancing objrmap with more advanced spatial algorithms,
pagetable reclamation, and possibly even shoving pte_chains in highmem
are better directions for alleviating the space and/or time overhead of
pte_chains, in no small part because they're direct attacks on the issue.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 12:08 ` 2.5.68-mm2 Ed Tomlinson
2003-04-23 12:37 ` 2.5.68-mm2 William Lee Irwin III
@ 2003-04-23 14:25 ` Martin J. Bligh
1 sibling, 0 replies; 27+ messages in thread
From: Martin J. Bligh @ 2003-04-23 14:25 UTC (permalink / raw)
To: Ed Tomlinson, Andrew Morton, linux-mm
> As far as I see it there are two problems that objrmap/shpte/pgcl try to
> solve. One is low memory pte useage, the second being to reduce the rmap
> fork overhead.
As Bill said, I'd leave pgcl out of this one.
> objrmap helps in both cases but has problem with truncate and intoduces a
> O(n^2) search into the the vm.
you forgot the end of that sentence ... "in one obscure corner case that's
already solved by sys_remap_file_pages."
I don't know of a problem with truncate, at least without the sorting code,
which seems to introduce i_shared_sem contention.
It also has some problems interacting with sys_remap_file_pages, which
people have already worked out how to fix, and Andrea posted a proposal for
yesterday.
>> From comments recently made on lkml I believe that the first problem is
>> probably
> more pressing. What problems need to be resolved with each patch?
shpte still has some odd corner-case issues though it works fine for most
circumstances. I can update it for the latest kernel again, but there's not
much point until Dave has some more time to work on it.
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 8:20 2.5.68-mm2 Andrew Morton
2003-04-23 9:59 ` 2.5.68-mm2 William Lee Irwin III
2003-04-23 12:08 ` 2.5.68-mm2 Ed Tomlinson
@ 2003-04-23 14:51 ` Martin J. Bligh
2003-04-23 15:14 ` 2.5.68-mm2 Alex Tomas
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
2003-05-01 6:19 ` [BUG] 2.5.68-mm2 and list.h Alexander Hoogerhuis
3 siblings, 2 replies; 27+ messages in thread
From: Martin J. Bligh @ 2003-04-23 14:51 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm
> . I got tired of the objrmap code going BUG under stress, so it is now in
> disgrace in the experimental/ directory.
Any chance of some more info on that? BUG at what point in the code,
and with what test to reproduce?
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-23 15:14 ` Alex Tomas
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
1 sibling, 0 replies; 27+ messages in thread
From: Alex Tomas @ 2003-04-23 15:14 UTC (permalink / raw)
Cc: Andrew Morton, linux-kernel, linux-mm
>>>>> Martin J Bligh (MJB) writes:
>> . I got tired of the objrmap code going BUG under stress, so it is now in
>> disgrace in the experimental/ directory.
MJB> Any chance of some more info on that? BUG at what point in the code,
MJB> and with what test to reproduce?
I've seen this running fsx-linux on ext3
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
2003-04-23 15:14 ` 2.5.68-mm2 Alex Tomas
@ 2003-04-23 21:46 ` Andrew Morton
2003-04-23 21:47 ` 2.5.68-mm2 Martin J. Bligh
2003-04-24 3:36 ` 2.5.68-mm2 Benjamin LaHaise
1 sibling, 2 replies; 27+ messages in thread
From: Andrew Morton @ 2003-04-23 21:46 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: linux-kernel, linux-mm
"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> > . I got tired of the objrmap code going BUG under stress, so it is now in
> > disgrace in the experimental/ directory.
>
> Any chance of some more info on that? BUG at what point in the code,
> and with what test to reproduce?
A bash-shared-mapping (from ext3 CVS) will quickly knock it over. It gets
its PageAnon/page->mapping state tangled up.
Must confess that I have trouble getting excited over objrmap. It introduces
- inconsistency (pte_chains versus vma-list scanning)
- code complexity
- a quadratic search
- nasty, nasty problems with remap_file_pages(). I'd rather not have to
nobble remap_file_pages() functionality for this reason.
and what do we gain from it all? The small fork/exec boost isn't very
significant. What we gain is more lowmem space on
going-away-real-soon-now-we-sincerely-hope highmem boxes.
Ingo-rmap seems a better solution to me. It would be a fairly large change
though - we'd have to hold the four atomic kmaps across an entire pte page
in copy_page_range(), for example. But it will then have good locality of
reference between adjacent pages and may well be quicker than pte_chains.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
@ 2003-04-23 21:47 ` Martin J. Bligh
2003-04-24 3:39 ` 2.5.68-mm2 Benjamin LaHaise
2003-04-24 3:36 ` 2.5.68-mm2 Benjamin LaHaise
1 sibling, 1 reply; 27+ messages in thread
From: Martin J. Bligh @ 2003-04-23 21:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
>> > . I got tired of the objrmap code going BUG under stress, so it is now in
>> > disgrace in the experimental/ directory.
>>
>> Any chance of some more info on that? BUG at what point in the code,
>> and with what test to reproduce?
>
> A bash-shared-mapping (from ext3 CVS) will quickly knock it over. It gets
> its PageAnon/page->mapping state tangled up.
OK, will try to reproduce that.
> - nasty, nasty problems with remap_file_pages(). I'd rather not have to
> nobble remap_file_pages() functionality for this reason.
I don't see having to predeclare the thing as non-linear as a serious
imposition .... I don't think memlocking them is necessary, AFAICS if
we have that.
> and what do we gain from it all? The small fork/exec boost isn't very
> significant. What we gain is more lowmem space on
> going-away-real-soon-now-we-sincerely-hope highmem boxes.
They're not going away soon (unfortunately) - even if Intel stopped producing
the chips today, the machines based on them are still in the marketplace for
years.
The performance improvement was about 25% of systime according to my
measurements - I don't call that insignificant.
> Ingo-rmap seems a better solution to me. It would be a fairly large change
> though - we'd have to hold the four atomic kmaps across an entire pte page
> in copy_page_range(), for example. But it will then have good locality of
> reference between adjacent pages and may well be quicker than pte_chains.
If there was an existing implementation we could actually measure, I'd
be more impressed. From what I can see currently, it'll just introduce
masses of kmap thrashing crap with no obvious way to fix it. And it
triples the PTE overhead. Maybe it'd work better in conjunction with
shared pagetables.
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 21:47 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-24 3:39 ` Benjamin LaHaise
2003-04-24 21:13 ` 2.5.68-mm2 Martin J. Bligh
0 siblings, 1 reply; 27+ messages in thread
From: Benjamin LaHaise @ 2003-04-24 3:39 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Andrew Morton, linux-kernel, linux-mm
On Wed, Apr 23, 2003 at 02:47:32PM -0700, Martin J. Bligh wrote:
> The performance improvement was about 25% of systime according to my
> measurements - I don't call that insignificant.
Never, ever use changes in system time as a justification for a patch. We
all know that Linux's user/system time accounting is patently unreliable.
Remember Nyquist? Talk to me about differences in wall clock and your
comments will be more interesting.
-ben
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-24 3:39 ` 2.5.68-mm2 Benjamin LaHaise
@ 2003-04-24 21:13 ` Martin J. Bligh
2003-04-24 23:13 ` objrmap (was 2.5.68-mm2) Martin J. Bligh
0 siblings, 1 reply; 27+ messages in thread
From: Martin J. Bligh @ 2003-04-24 21:13 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Andrew Morton, linux-kernel, linux-mm
>> The performance improvement was about 25% of systime according to my
>> measurements - I don't call that insignificant.
>
> Never, ever use changes in system time as a justification for a patch. We
> all know that Linux's user/system time accounting is patently unreliable.
Mmmm. I'm not particularly convinced by that ... I do 5 runs for every
benchmark and compare the results, and it seems very consistent to me.
For kernbench, it's interesting to look at system time - but obviously
keeping an eye on elapsed time as well, particularly for things like
scheduler patches.
> Remember Nyquist? Talk to me about differences in wall clock and your
> comments will be more interesting.
OK, well then you need to look at something that's not totally dominated
by gcc anyway. I know everyone hates SDET as it's "closed" but I'll try
to rerun with aim7 at some point. A real 20% improvement in throughput
is not to be sniffed at ...
DISCLAIMER: SPEC(tm) and the benchmark name SDET(tm) are registered
trademarks of the Standard Performance Evaluation Corporation. This
benchmarking was performed for research purposes only, and the run results
are non-compliant and not-comparable with any published results.
Results are shown as percentages of the first set displayed
SDET 1 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.7%
2.5.68-objrmap 105.7% 0.4%
SDET 2 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 2.8%
2.5.68-objrmap 108.2% 0.7%
SDET 4 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 1.0%
2.5.68-objrmap 112.0% 1.4%
SDET 8 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.6%
2.5.68-objrmap 122.8% 1.3%
SDET 16 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.1%
2.5.68-objrmap 117.3% 0.8%
SDET 32 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.4%
2.5.68-objrmap 118.5% 0.4%
SDET 64 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.2%
2.5.68-objrmap 121.2% 0.3%
SDET 128 (see disclaimer)
Throughput Std. Dev
2.5.68 100.0% 0.1%
2.5.68-objrmap 118.6% 0.2%
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: objrmap (was 2.5.68-mm2)
2003-04-24 21:13 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-24 23:13 ` Martin J. Bligh
0 siblings, 0 replies; 27+ messages in thread
From: Martin J. Bligh @ 2003-04-24 23:13 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Andrew Morton, linux-kernel, linux-mm
> OK, well then you need to look at something that's not totally dominated
> by gcc anyway. I know everyone hates SDET as it's "closed" but I'll try
> to rerun with aim7 at some point. A real 20% improvement in throughput
> is not to be sniffed at ...
BTW, if you want to see the profile for this, it's obvious what's
taking the time ...
86159 page_remove_rmap
38690 page_add_rmap
17976 zap_pte_range
14431 copy_page_range
10953 __d_lookup
9978 release_pages
9369 find_get_page
7483 atomic_dec_and_lock
6924 __copy_to_user_ll
6830 kmem_cache_free
5848 path_lookup
4687 follow_mount
4430 clear_page_tables
4214 remove_shared_vm_struct
3907 do_wp_page
3823 .text.lock.dec_and_lock
3336 do_no_page
3315 do_anonymous_page
3294 copy_mm
3279 free_pages_and_swap_cache
3111 pte_alloc_one
2709 .text.lock.dcache
2625 .text.lock.filemap
2573 filemap_nopage
2564 copy_process
2556 proc_pid_stat
2358 link_path_walk
2246 do_page_fault
2202 file_move
2189 buffered_rmqueue
2141 free_hot_cold_page
2140 schedule
2114 path_release
1879 current_kernel_time
1825 .text.lock.namei
1722 d_alloc
1719 release_task
1490 __set_page_dirty_buffers
1464 number
1350 kmalloc
1343 __read_lock_failed
1305 page_address
1286 fd_install
1255 __find_get_block
1253 flush_signal_handlers
1249 __fput
1248 exit_notify
1242 task_mem
1221 grab_block
1188 .text.lock.highmem
1169 __block_prepare_write
1123 __brelse
1050 file_kill
1026 .text.lock.file_table
1013 ext2_new_inode
1008 __mark_inode_dirty
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-23 21:46 ` 2.5.68-mm2 Andrew Morton
2003-04-23 21:47 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-24 3:36 ` Benjamin LaHaise
2003-04-24 20:24 ` 2.5.68-mm2 Bill Davidsen
1 sibling, 1 reply; 27+ messages in thread
From: Benjamin LaHaise @ 2003-04-24 3:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: Martin J. Bligh, linux-kernel, linux-mm
On Wed, Apr 23, 2003 at 02:46:48PM -0700, Andrew Morton wrote:
> Ingo-rmap seems a better solution to me. It would be a fairly large change
> though - we'd have to hold the four atomic kmaps across an entire pte page
> in copy_page_range(), for example. But it will then have good locality of
> reference between adjacent pages and may well be quicker than pte_chains.
Actually, Ingo's rmap style sounds very similar to what I first implemented
in one of my stabs at rmap. It has a nasty side effect of being worst case
for cache organisation -- the sister page tends to map to the exact same
cache line in some processors. Whoops. That said, I think that the rmap
pte-chains can really stand a bit of optimization by means of discarding a
couple of bits, as well as merging for adjacent pages, so I don't think
the overhead is a lost cause yet. And nobody has written the clone() patch
for bash yet...
-ben
--
Junk email? <a href="mailto:aart@kvack.org">aart@kvack.org</a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-24 3:36 ` 2.5.68-mm2 Benjamin LaHaise
@ 2003-04-24 20:24 ` Bill Davidsen
2003-04-24 20:33 ` 2.5.68-mm2 Benjamin LaHaise
0 siblings, 1 reply; 27+ messages in thread
From: Bill Davidsen @ 2003-04-24 20:24 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Andrew Morton, Martin J. Bligh, linux-kernel, linux-mm
On Wed, 23 Apr 2003, Benjamin LaHaise wrote:
> Actually, Ingo's rmap style sounds very similar to what I first implemented
> in one of my stabs at rmap. It has a nasty side effect of being worst case
> for cache organisation -- the sister page tends to map to the exact same
> cache line in some processors. Whoops. That said, I think that the rmap
> pte-chains can really stand a bit of optimization by means of discarding a
> couple of bits, as well as merging for adjacent pages, so I don't think
> the overhead is a lost cause yet. And nobody has written the clone() patch
> for bash yet...
I'm not sure the best solution is to try to hack applications doing things
in the way they find best. I suspect that we have to change the kernel so
it handles the requests in a reasonable way.
Of course reasonable way may mean that bash does some things a bit slower,
but given that the whole thing works well in most cases anyway, I think
the kernel handling the situation is preferable.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-24 20:24 ` 2.5.68-mm2 Bill Davidsen
@ 2003-04-24 20:33 ` Benjamin LaHaise
2003-04-25 17:56 ` 2.5.68-mm2 Bill Davidsen
0 siblings, 1 reply; 27+ messages in thread
From: Benjamin LaHaise @ 2003-04-24 20:33 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Andrew Morton, Martin J. Bligh, linux-kernel, linux-mm
On Thu, Apr 24, 2003 at 04:24:56PM -0400, Bill Davidsen wrote:
> Of course reasonable way may mean that bash does some things a bit slower,
> but given that the whole thing works well in most cases anyway, I think
> the kernel handling the situation is preferable.
Eh? It makes bash _faster_ for all cases of starting up a child process.
And it even works on 2.4 kernels.
-ben
--
Junk email? <a href="mailto:aart@kvack.org">aart@kvack.org</a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-24 20:33 ` 2.5.68-mm2 Benjamin LaHaise
@ 2003-04-25 17:56 ` Bill Davidsen
2003-04-25 18:20 ` 2.5.68-mm2 Randy.Dunlap
0 siblings, 1 reply; 27+ messages in thread
From: Bill Davidsen @ 2003-04-25 17:56 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Andrew Morton, Martin J. Bligh, linux-kernel, linux-mm
On Thu, 24 Apr 2003, Benjamin LaHaise wrote:
> On Thu, Apr 24, 2003 at 04:24:56PM -0400, Bill Davidsen wrote:
> > Of course reasonable way may mean that bash does some things a bit slower,
> > but given that the whole thing works well in most cases anyway, I think
> > the kernel handling the situation is preferable.
>
> Eh? It makes bash _faster_ for all cases of starting up a child process.
> And it even works on 2.4 kernels.
The point is that even if bash is fixed it's desirable to address the
issue in the kernel, other applications may well misbehave as well.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-25 17:56 ` 2.5.68-mm2 Bill Davidsen
@ 2003-04-25 18:20 ` Randy.Dunlap
2003-04-25 18:27 ` 2.5.68-mm2 Robert Love
0 siblings, 1 reply; 27+ messages in thread
From: Randy.Dunlap @ 2003-04-25 18:20 UTC (permalink / raw)
To: Bill Davidsen; +Cc: bcrl, akpm, mbligh, linux-kernel, linux-mm
On Fri, 25 Apr 2003 13:56:31 -0400 (EDT) Bill Davidsen <davidsen@tmr.com> wrote:
| On Thu, 24 Apr 2003, Benjamin LaHaise wrote:
|
| > On Thu, Apr 24, 2003 at 04:24:56PM -0400, Bill Davidsen wrote:
| > > Of course reasonable way may mean that bash does some things a bit slower,
| > > but given that the whole thing works well in most cases anyway, I think
| > > the kernel handling the situation is preferable.
| >
| > Eh? It makes bash _faster_ for all cases of starting up a child process.
| > And it even works on 2.4 kernels.
|
| The point is that even if bash is fixed it's desirable to address the
| issue in the kernel, other applications may well misbehave as well.
So when would this ever end?
--
~Randy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-25 18:20 ` 2.5.68-mm2 Randy.Dunlap
@ 2003-04-25 18:27 ` Robert Love
2003-04-25 18:49 ` 2.5.68-mm2 Martin J. Bligh
2003-04-26 10:34 ` 2.5.68-mm2 Bill Davidsen
0 siblings, 2 replies; 27+ messages in thread
From: Robert Love @ 2003-04-25 18:27 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Bill Davidsen, bcrl, akpm, mbligh, linux-kernel, linux-mm
On Fri, 2003-04-25 at 14:20, Randy.Dunlap wrote:
>
> | The point is that even if bash is fixed it's desirable to address the
> | issue in the kernel, other applications may well misbehave as well.
>
> So when would this ever end?
Exactly what I was thinking.
The kernel cannot be expected to cater to applications or make
concessions (read: hacks) for certain behavior. If we offer a cleaner,
improved interface which offers the performance improvement, we are
done. Applications need to start using it.
Of course, I am not arguing against optimizing the old interfaces or
anything of that nature. I just believe we should not introduce hacks
for application behavior. It is their job to do the right thing.
Robert Love
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-25 18:27 ` 2.5.68-mm2 Robert Love
@ 2003-04-25 18:49 ` Martin J. Bligh
2003-04-26 10:34 ` 2.5.68-mm2 Bill Davidsen
1 sibling, 0 replies; 27+ messages in thread
From: Martin J. Bligh @ 2003-04-25 18:49 UTC (permalink / raw)
To: Robert Love, Randy.Dunlap
Cc: Bill Davidsen, bcrl, akpm, linux-kernel, linux-mm
>> | The point is that even if bash is fixed it's desirable to address the
>> | issue in the kernel, other applications may well misbehave as well.
>>
>> So when would this ever end?
>
> Exactly what I was thinking.
>
> The kernel cannot be expected to cater to applications or make
> concessions (read: hacks) for certain behavior. If we offer a cleaner,
> improved interface which offers the performance improvement, we are
> done. Applications need to start using it.
>
> Of course, I am not arguing against optimizing the old interfaces or
> anything of that nature. I just believe we should not introduce hacks
> for application behavior. It is their job to do the right thing.
I would actually like us to do this (the non-deterministic nature of UNIX
semantics wrt exec is hateful), but changing the kernel before the apps is
ass-backwards. Once this distros fix all their binaries (at least in their
bleeding edge versions) this makes more sense.
There are also some interesting comments the manpage for vfork:
BUGS
It is rather unfortunate that Linux revived this spectre
from the past. The BSD manpage states: "This system call
will be eliminated when proper system sharing mechanisms
are implemented. Users should not depend on the memory
sharing semantics of vfork as it will, in that case, be
made synonymous to fork."
Formally speaking, the standard description given above
does not allow one to use vfork() since a following exec
might fail, and then what happens is undefined.
Details of the signal handling are obscure and differ
between systems. The BSD manpage states: "To avoid a pos-
sible deadlock situation, processes that are children in
the middle of a vfork are never sent SIGTTOU or SIGTTIN
signals; rather, output or ioctls are allowed and input
attempts result in an end-of-file indication."
Currently (Linux 2.3.25), strace(1) cannot follow vfork()
and requires a kernel patch.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: 2.5.68-mm2
2003-04-25 18:27 ` 2.5.68-mm2 Robert Love
2003-04-25 18:49 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-04-26 10:34 ` Bill Davidsen
2003-04-26 15:34 ` 2.5.68-mm2 Martin J. Bligh
1 sibling, 1 reply; 27+ messages in thread
From: Bill Davidsen @ 2003-04-26 10:34 UTC (permalink / raw)
To: Robert Love; +Cc: Randy.Dunlap, bcrl, akpm, mbligh, linux-kernel, linux-mm
On 25 Apr 2003, Robert Love wrote:
> On Fri, 2003-04-25 at 14:20, Randy.Dunlap wrote:
> >
> > | The point is that even if bash is fixed it's desirable to address the
> > | issue in the kernel, other applications may well misbehave as well.
> >
> > So when would this ever end?
>
> Exactly what I was thinking.
>
> The kernel cannot be expected to cater to applications or make
> concessions (read: hacks) for certain behavior. If we offer a cleaner,
> improved interface which offers the performance improvement, we are
> done. Applications need to start using it.
>
> Of course, I am not arguing against optimizing the old interfaces or
> anything of that nature. I just believe we should not introduce hacks
> for application behavior. It is their job to do the right thing.
I don't care much if the kernel does something to make an application run
better, that's an application problem. But if an application can do
something which hurts the performance of the system as a whole, then the
kernel should protect itself and the rest of the system.
So I'm not advocating that the kernel cater to bash, just that doing
legitimate things with bash not have a disproportionate impact on the rest
of the system.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.68-mm2
2003-04-26 10:34 ` 2.5.68-mm2 Bill Davidsen
@ 2003-04-26 15:34 ` Martin J. Bligh
0 siblings, 0 replies; 27+ messages in thread
From: Martin J. Bligh @ 2003-04-26 15:34 UTC (permalink / raw)
To: Bill Davidsen, Robert Love
Cc: Randy.Dunlap, bcrl, akpm, linux-kernel, linux-mm
>> > | The point is that even if bash is fixed it's desirable to address the
>> > | issue in the kernel, other applications may well misbehave as well.
>> >
>> > So when would this ever end?
>>
>> Exactly what I was thinking.
>>
>> The kernel cannot be expected to cater to applications or make
>> concessions (read: hacks) for certain behavior. If we offer a cleaner,
>> improved interface which offers the performance improvement, we are
>> done. Applications need to start using it.
>>
>> Of course, I am not arguing against optimizing the old interfaces or
>> anything of that nature. I just believe we should not introduce hacks
>> for application behavior. It is their job to do the right thing.
>
> I don't care much if the kernel does something to make an application run
> better, that's an application problem. But if an application can do
> something which hurts the performance of the system as a whole, then the
> kernel should protect itself and the rest of the system.
>
> So I'm not advocating that the kernel cater to bash, just that doing
> legitimate things with bash not have a disproportionate impact on the rest
> of the system.
It's not just bash ... it's most applications.
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread
* [BUG] 2.5.68-mm2 and list.h
2003-04-23 8:20 2.5.68-mm2 Andrew Morton
` (2 preceding siblings ...)
2003-04-23 14:51 ` 2.5.68-mm2 Martin J. Bligh
@ 2003-05-01 6:19 ` Alexander Hoogerhuis
2003-05-01 6:31 ` Andrew Morton
3 siblings, 1 reply; 27+ messages in thread
From: Alexander Hoogerhuis @ 2003-05-01 6:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Morton <akpm@digeo.com> writes:
>
> [SNIP]
>
Caught this one on boot:
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.0
Bluetooth: Core ver 2.2
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: HCI USB driver ver 2.1
drivers/usb/core/usb.c: registered new driver hci_usb
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
- ------------[ cut here ]------------
kernel BUG at include/linux/list.h:140!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<c011acc2>] Not tainted VLI
EFLAGS: 00010083
EIP is at remove_wait_queue+0x66/0x70
eax: ec937d94 ebx: ec936000 ecx: ec937da0 edx: ec797d28
esi: 00000286 edi: ec937d94 ebp: ec937d58 esp: ec937d50
ds: 007b es: 007b ss: 0068
Process logger (pid: 3942, threadinfo=ec936000 task=edede700)
Stack: ec797d28 ec936000 ec937dc0 c019e462 c02fff00 00000002 c0117b14 ec797d24
effb1600 00000000 edede700 c0119716 00000000 00000000 00000000 ec937ee7
ecaa5df0 00000000 edede700 c0119716 ec797d28 ec797d28 ec937ee7 0026c8ca
Call Trace:
[<c019e462>] devfs_d_revalidate_wait+0x181/0x18d
[<c0117b14>] do_page_fault+0x0/0x4bf
[<c0119716>] default_wake_function+0x0/0x12
[<c0119716>] default_wake_function+0x0/0x12
[<c015add3>] do_lookup+0x5c/0x98
[<c015b2c6>] link_path_walk+0x4b7/0x8fd
[<c01350cd>] file_read_actor+0x0/0x11f
[<c01350cd>] file_read_actor+0x0/0x11f
[<c029d529>] unix_find_other+0x2e/0x158
[<c029dac4>] unix_dgram_connect+0xfb/0x1a5
[<c024a9ec>] sys_connect+0xa9/0xb1
[<c024953d>] sock_map_fd+0x118/0x12e
[<c024a586>] sys_socket+0x3a/0x56
[<c024b50f>] sys_socketcall+0xb2/0x262
[<c015ef49>] do_fcntl+0xd8/0x1a4
[<c015f0fa>] sys_fcntl64+0x6f/0xab
[<c010ae57>] syscall_call+0x7/0xb
Code: 43 08 83 e0 08 75 0b 8b 1c 24 8b 74 24 04 89 ec 5d c3 8b 1c 24 8b 74 24 04 89 ec 5d e9 0e ea ff ff 0f 0b 8d 00 12 42 2b c0 eb c9 <0f> 0b 8c 00 12 42 2b c0 eb b7 55 89 e5 83 ec 0c 89 1c 24 89 74
<6>note: logger[3942] exited with preempt_count 1
bad: scheduling while atomic!
Call Trace:
[<c01196c1>] schedule+0x3f1/0x3f6
[<c013f9f6>] unmap_page_range+0x41/0x67
[<c013fbd1>] unmap_vmas+0x1b5/0x216
[<c01437da>] exit_mmap+0x7a/0x18d
[<c010b920>] do_invalid_op+0x0/0xb7
[<c011b0f2>] mmput+0x67/0xcf
[<c011ee19>] do_exit+0x159/0x485
[<c010b920>] do_invalid_op+0x0/0xb7
[<c010b611>] do_divide_error+0x0/0xde
[<c010b9d5>] do_invalid_op+0xb5/0xb7
[<c011acc2>] remove_wait_queue+0x66/0x70
[<c0117d92>] do_page_fault+0x27e/0x4bf
[<c010b001>] error_code+0x2d/0x38
[<c011acc2>] remove_wait_queue+0x66/0x70
[<c019e462>] devfs_d_revalidate_wait+0x181/0x18d
[<c0117b14>] do_page_fault+0x0/0x4bf
[<c0119716>] default_wake_function+0x0/0x12
[<c0119716>] default_wake_function+0x0/0x12
[<c015add3>] do_lookup+0x5c/0x98
[<c015b2c6>] link_path_walk+0x4b7/0x8fd
[<c01350cd>] file_read_actor+0x0/0x11f
[<c01350cd>] file_read_actor+0x0/0x11f
[<c029d529>] unix_find_other+0x2e/0x158
[<c029dac4>] unix_dgram_connect+0xfb/0x1a5
[<c024a9ec>] sys_connect+0xa9/0xb1
[<c024953d>] sock_map_fd+0x118/0x12e
[<c024a586>] sys_socket+0x3a/0x56
[<c024b50f>] sys_socketcall+0xb2/0x262
[<c015ef49>] do_fcntl+0xd8/0x1a4
[<c015f0fa>] sys_fcntl64+0x6f/0xab
[<c010ae57>] syscall_call+0x7/0xb
and with modular USB I also get this along for free, right after:
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -110
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -75
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -110
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -75
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -110
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -110
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -75
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -110
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -75
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -110
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -110
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 9 ret -75
drivers/usb/core/message.c: usb_control/bulk_msg: timeout
usbfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -110
.config is attached.
mvh,
A
- --
Alexander Hoogerhuis | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQE+sLyBCQ1pa+gRoggRAqPjAJoDxrfbRyPlEzUU0V14WzPhSmPXaQCfThba
/nN9EqynPWOUo+F3T8P6uBE=
=C+e/
-----END PGP SIGNATURE-----
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [BUG] 2.5.68-mm2 and list.h
2003-05-01 6:19 ` [BUG] 2.5.68-mm2 and list.h Alexander Hoogerhuis
@ 2003-05-01 6:31 ` Andrew Morton
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Morton @ 2003-05-01 6:31 UTC (permalink / raw)
To: Alexander Hoogerhuis; +Cc: linux-kernel, linux-mm
Alexander Hoogerhuis <alexh@ihatent.com> wrote:
>
> kernel BUG at include/linux/list.h:140!
> Call Trace:
> [<c019e462>] devfs_d_revalidate_wait+0x181/0x18d
Yes. Apparently, devfs has some programming flaws.
For now, please just delete the new debug tests in
include/linux/list.h:list_del():
#include <linux/kernel.h> /* BUG_ON */
static inline void list_del(struct list_head *entry)
{
BUG_ON(entry->prev->next != entry);
BUG_ON(entry->next->prev != entry);
__list_del(entry->prev, entry->next);
}
Those BUG_ON's.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 27+ messages in thread