On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > Why? What's so special about the name 'ttyS'?
>
> It's the name that users of Linux expect built-in serial ports to have.
Not really. The norm under Linux is for non-8250 ports to use
properly-registered
On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
David Woodhouse writes:
Why? What's so special about the name 'ttyS'?
It's the name that users of Linux expect built-in serial ports to have.
Not really. The norm under Linux is for non-8250 ports to use
properly-registered device
Mark Lord wrote:
Ideally, this would go into linux-2.6.21.
Preserve the LBA bit in the DevSel/Head register for HDIO_DRIVE_TASK.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- linux/drivers/ata/libata-scsi.c.orig2007-03-21
13:35:02.0 -0400
+++ linux/drivers/ata/libata-scsi.c
Eric Dumazet wrote:
Nick Piggin a écrit :
Eric Dumazet wrote:
I do think such workloads might benefit from a vma_cache not shared
by all threads but private to each thread. A sequence could
invalidate the cache(s).
ie instead of a mm-mmap_cache, having a mm-sequence, and each
thread
Robert Hancock wrote:
This adds some NCQ blacklist entries taken from the Silicon Image 3124/3132
Windows driver .inf files. There are some confirming reports of problems
with these drives under Linux (for example
http://lkml.org/lkml/2007/3/4/178)
so let's disable NCQ on these drives.
On Tue, Apr 03 2007, Pekka J Enberg wrote:
mcdx:: close()
However, we never hit do_mcdx_request(). Jens, do we need to do
set_capacity() somewhere? I don't see other cdrom drivers doing it but
they could be broken too...
Yeah, that would be appropriate.
--
Jens Axboe
-
To unsubscribe
On Tue, 3 Apr 2007, Matt Mackall wrote:
Make /proc/pid/clear_refs option under CONFIG_EMBEDDED
This interface is primarily useful for doing memory profiling and not
much use on deployed embedded boxes. Make it optional. Together with
/proc/pid/smaps, this save a few K.
Signed-off-by:
On Wed, 04 Apr 2007 16:09:40 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew, do you have any objections to putting Eric's fairly
important patch at least into -mm?
you know what to do ;)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
[PATCH] Just include linux/kallsyms.h all the time as the header will
handle prototypes/defines when CONFIG_KALLSYMS is disabled ... fixes
build error when disabled due to print_ip_sym not being macroed away
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
arch/blackfin/kernel/traps.c |5 ++---
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
include/asm-blackfin/socket.h | 55
include/asm-blackfin/sockios.h | 13 +
2 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 include/asm-blackfin/socket.h
create mode 100644
USB gadget rndis: skb_push function may return a pointer which is not
aligned as required by struct rndis_packet_msg_type.
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
drivers/usb/gadget/rndis.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
mm/nommu.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 2d0a82f..0016557 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -261,6 +261,14 @@ void vunmap(void *addr)
}
/*
+ * Implement a
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
arch/blackfin/kernel/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index ce51882..9870c60 100644
--- a/arch/blackfin/kernel/setup.c
+++
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
include/asm-blackfin/pgtable.h | 44 +++
1 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/include/asm-blackfin/pgtable.h b/include/asm-blackfin/pgtable.h
index 9328537..5a8f9e4 100644
---
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
arch/blackfin/lib/memchr.S | 31 +---
arch/blackfin/lib/memcmp.S | 46 ++
arch/blackfin/lib/memcpy.S | 24 +++---
arch/blackfin/lib/memmove.S | 12 ++
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
include/asm-blackfin/uaccess.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/asm-blackfin/uaccess.h b/include/asm-blackfin/uaccess.h
index ed931bb..bfcb679 100644
--- a/include/asm-blackfin/uaccess.h
+++
On 4/4/07, Rene Herman [EMAIL PROTECTED] wrote:
Taking forever to reproduce in as far as getting the oops. The thing is
now just locking hard each time. Will keep on trying...
Can you get anything out with sysrq-t? The original oops would be
enough to conclude it's a double-free if it weren't
David Woodhouse writes:
It 'should' be the case because that is what is easiest for users and
makes most sense from a user's point of view.
I really don't buy that argument. People cope perfectly well
with /dev/ttySA0 on StrongARM, with /dev/ttySC0 on SH, etc. If it isn't
Those are
On Wed, 4 Apr 2007, Antoine Martin wrote:
and this one:
http://www.suse.de/~kraxel/uml/patches/2.6.18-rc4/uml-x11-fb
which applied cleanly, but is not letting me set the option - Kconfig is
beyond me:
arch/um/Kconfig:144:warning: 'select' used by config symbol 'X11_FB' refer to
undefined
On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote:
[...]
Well, it works for me on 32-bit as well, right up to 100% full.
No problems at all...
Maybe it depends on the kernel. I patched 2.6.20 with the patches
above and got the described behaviour.
Regards,
Tino
-
To unsubscribe from
On Tue, Apr 03, 2007 at 03:55:32PM +0200, Bernhard Kaindl wrote:
PS: I attached a program which uses msr.ko (CONFIG_X86_MSR) from
Processor type and features
- [M/*] /dev/cpu/*/msr - Model-specific register support
to dump the contents of the fixed-range MTTRs to stdout.
On a
(sorry to change the subjet, I was initially going to send the
threaded vma cache patches on list, but then decided they didn't
have enough changelog!)
Andrew Morton wrote:
On Wed, 04 Apr 2007 16:09:40 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew, do you have any objections to putting
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-core.c | 33 -
drivers/ata/libata-eh.c | 22 +++---
On Tue, 2007-04-03 at 20:22 -0700, Randy Dunlap wrote:
+/**
+ * val_outside - is a value and length past a limit?
+ * @val: the start value
+ * @len: the length from the start
+ * @limit: the first invalid value
+ *
+ * Like val + len limit, except with overflow checking.
+ */
Nick Piggin wrote:
Sad. Although Ulrich did seem interested at one point I think? Ulrich,
do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Ulrich Drepper wrote:
Nick Piggin wrote:
Sad. Although Ulrich did seem interested at one point I think? Ulrich,
do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
Private futexes.
--
SUSE Labs, Novell Inc.
-
To unsubscribe from
On Tue, Apr 03, 2007 at 07:04:58PM -0700, Paul Jackson wrote:
Andrew wrote:
I'd have thought that in general an application should be querying its
present affinity mask - something like sched_getaffinity()? That fixes the
CPU hotplug issues too, of course.
The sched_getaffinity call is
Ulrich Drepper a écrit :
Nick Piggin wrote:
Sad. Although Ulrich did seem interested at one point I think? Ulrich,
do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
You were CC on this one, you can find an archive here :
On Wed, 2007-04-04 at 14:28 +0800, Wu, Bryan wrote:
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
include/asm-blackfin/socket.h | 55
include/asm-blackfin/sockios.h | 13 +
2 files changed, 68 insertions(+), 0 deletions(-)
create mode
Eric Dumazet wrote:
You were CC on this one, you can find an archive here :
You cc:ed my gmail account. I don't pick out mails sent to me there.
If you want me to look at something you have to send it to my
@redhat.com address.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain
David Woodhouse writes:
A GUI PPP dialer should be
listing the available serial ports in the system whatever their names
are.
How do you propose they do that? Neither kppp nor gnome-ppp seem to
be able to do that currently. Gnome-ppp offers just /dev/modem and
/dev/ttyS[0123]. Kppp offers
On Mon, Apr 02, 2007 at 11:51:09PM -0400, Rob Landley wrote:
So make oldconfig ARCH=powerpc will accept a config that doesn't have a
platform selected?
It seems so.
I think the patch below will fix that by forcing at least one platform
to be selected. Can you try it and see if it helps
On Tue, 3 Apr 2007, David Miller wrote:
From: Paul Mackerras [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 09:14:20 +1000
David Woodhouse writes:
There are proper device numbers registered for pmac_zilog now. Use them.
Sigh. I guess this is inevitable, but IMNSHO this exposes a
On 4/3/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Tue, Apr 03, 2007 at 09:04:59PM -0700, Paul Menage wrote:
Have you posted the cpuset implementation over your system yet?
Yep, here:
http://lists.linux-foundation.org/pipermail/containers/2007-March/001497.html
For some reason, the
Jakub wrote:
OpenMP wants (4) and I'll change it that way.
Good. Are you referring to a change in glibc or in OpenMP?
sysconf(_SC_NPROCESSORS_ONLN) must return (3) (this currently scans
/proc/stat)
Ok
sysconf(_SC_NPROCESSORS_CONF) should IMHO return (2) (this currently
scans
On Tue, 3 Apr 2007, David Miller wrote:
From: David Woodhouse [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 01:19:59 -0400
I don't see why that 'should' be the case. Certainly it _isn't_ the case
on most supported platforms -- we have separate device numbers, and
names, for most types of
On 3/15/07, Eric Dumazet [EMAIL PROTECTED] wrote:
But fact is POSIX defined PRIVATE and SHARED, allowing clear separation, and
optimal performance if carefuly implemented. Time has come for linux to have
better threading performance.
Now that I've been pointed to the thread I can comment on
On Tue, 03 Apr 2007 23:54:42 -0700
Ulrich Drepper [EMAIL PROTECTED] wrote:
Eric Dumazet wrote:
You were CC on this one, you can find an archive here :
You cc:ed my gmail account. I don't pick out mails sent to me there.
If you want me to look at something you have to send it to my
On Tue, Apr 03, 2007 at 05:05:20PM +0200, Miklos Szeredi wrote:
On Tue, 2007-04-03 at 18:21 +0400, Alexey Dobriyan wrote:
On Mon, Mar 26, 2007 at 11:35:42PM -0800, [EMAIL PROTECTED] wrote:
The patch titled
add file position info to proc
has been added to the -mm tree. Its
Ulrich Drepper wrote:
People might remember the thread about mysql not scaling and pointing
the finger quite happily at glibc. Well, the situation is not like that.
The problem is glibc has to work around kernel limitations. If the
malloc implementation detects that a large chunk of
04/04/2007 02:34 AM, Karl Pickett wrote/a écrit:
The ati_remote driver is a little too sensitive for my wife... if you
do anything but barely tap the button you can get multiple events
reported. We prefer a more conservative no-repeat setting. This is a
pretty trivial patch which just makes
On Tue, Apr 03, 2007 at 06:21:25PM -0700, David Miller wrote:
From: Alan Cox [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 02:19:24 +0100
I totally agree with Paul, the onboard serial device should get
ttyS0 regardless of what hardare is used to drive it.
Thats between you and udev.
On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote:
From: David Woodhouse [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 01:19:59 -0400
I don't see why that 'should' be the case. Certainly it _isn't_ the case
on most supported platforms -- we have separate device numbers, and
names,
Nick Piggin wrote:
Ulrich Drepper wrote:
People might remember the thread about mysql not scaling and pointing
the finger quite happily at glibc. Well, the situation is not like that.
The problem is glibc has to work around kernel limitations. If the
malloc implementation detects that a
Hi,
This patch has fixed build error on zs serial driver.
drivers/tc/zs.c:73:24: error: asm/dec/tc.h: No such file or directory
make[2]: *** [drivers/tc/zs.o] Error 1
Yoichi
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
diff -pruN -X mips/Documentation/dontdiff mips-orig/drivers/tc/zs.c
On Wed, 2007-04-04 at 14:55 +0800, Wu, Bryan wrote:
On Wed, 2007-04-04 at 14:28 +0800, Wu, Bryan wrote:
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
include/asm-blackfin/socket.h | 55
include/asm-blackfin/sockios.h | 13 +
2
From: David Woodhouse [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 02:03:54 -0400
On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
It 'should' be the case because that is what is easiest for users and
makes most sense from a user's point of view.
I really don't buy that argument.
I
On Apr 4 2007 13:42, Antonino A. Daplas wrote:
Does whatever defines what these escapes mean, have any comment to make
about UTF-8? If not, why can't we declare that UTF-8 mode is the reset
mode, the default that would be dropped to on a full reset, and if
anyone wanted to switch that
On Wed, Apr 04, 2007 at 05:46:12PM +1000, Nick Piggin wrote:
Does mmap(PROT_NONE) actually free the memory?
Yes.
/* Clear old maps */
error = -ENOMEM;
munmap_back:
vma = find_vma_prepare(mm, addr, prev, rb_link, rb_parent);
if (vma vma-vm_start addr + len) {
On Wed, 2007-04-04 at 12:22 +1000, Nick Piggin wrote:
Eric Dumazet wrote:
I do think such workloads might benefit from a vma_cache not shared by
all threads but private to each thread. A sequence could invalidate the
cache(s).
ie instead of a mm-mmap_cache, having a mm-sequence, and
On Wed, Apr 04, 2007 at 10:12:06AM +0200, Jan Engelhardt wrote:
On Apr 4 2007 13:42, Antonino A. Daplas wrote:
Please note that I have dropped this patch in favor of this one:
http://lkml.org/lkml/2007/4/2/422
^^ Which is ok by me.
I agree - Does The Right Thing as far as I'm concerned.
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
include/asm-blackfin/dma-mapping.h | 11 ++-
include/asm-blackfin/gpio.h|2 --
include/asm-blackfin/mach-bf533/anomaly.h |1 -
include/asm-blackfin/mach-bf533/blackfin.h |
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
include/asm-blackfin/socket.h | 11 ++-
include/asm-blackfin/sockios.h |3 ++-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/asm-blackfin/socket.h b/include/asm-blackfin/socket.h
index f337bb3..5213c96 100644
On Wed, Apr 04, 2007 at 01:12:08AM -0700, David Miller wrote:
Your ARM example holds zero water because that platform has all kinds
of weird devices so people there are used to all kinds of non-standard
conventions and naming.
I think your perception is more wrong than you could ever think.
From: Russell King [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 08:52:44 +0100
On Tue, Apr 03, 2007 at 10:50:06PM -0700, David Miller wrote:
From: David Woodhouse [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 01:19:59 -0400
I don't see why that 'should' be the case. Certainly it _isn't_ the case
From: Russell King [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 09:38:03 +0100
However, despite people pressing for it, there's yet to be a *sane*
*technical* *solution* to the problem. All I've seen so far is one
bad hack.
Well the bad hack we use on sparc gives usable serial ports,
properly
On 4/4/07, Éric Piel [EMAIL PROTECTED] wrote:
This default value is set to 300 ms. On my Xserver, the default value is
660 ms and by default in my distrib it's set to 500 ms. So, indeed, the
default value of the ati_remote is quite small. Maybe you could increase
FILTER_MAX to 10 (= 600 ms) in
* Dave Dillow [EMAIL PROTECTED] wrote:
Then it is a matter of figuring out why the device number changed --
I'm thinking it is device-mapper, but will look closer tomorrow.
This commit is the one that changed it:
commit fdf892be32d84a1745fa0aee5fc60517421b8038
Author: Andrew Morton
Jakub Jelinek wrote:
On Wed, Apr 04, 2007 at 05:46:12PM +1000, Nick Piggin wrote:
Does mmap(PROT_NONE) actually free the memory?
Yes.
/* Clear old maps */
error = -ENOMEM;
munmap_back:
vma = find_vma_prepare(mm, addr, prev, rb_link, rb_parent);
if (vma
* Rui Nuno Capela [EMAIL PROTECTED] wrote:
Ingo et al.
I'm afraid having no good news (once again). After building
2.6.21-rc5-rt8 and recently on -rt10 I've found some trouble running
on a Core2 T7200 laptop (SMP). Somehow, specially after starting
jackd, the whole system starts
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
diff -puN kernel/lockdep.c~simplify-kallsyms_lookup kernel/lockdep.c
--- a/kernel/lockdep.c~simplify-kallsyms_lookup
+++ a/kernel/lockdep.c
@@ -340,10 +340,7 @@ static const char *usage_str[] =
const char * __get_key_name(struct
This new version (v.2) fixes generic arch i386 up build, has (hopefully)
clearer explanations, and does not break git bisect searches.
---
With the advent of kdump, the assumption that the boot CPU when running
an UP kernel is always the CPU with a particular hardware ID (often 0)
(usually
With the advent of kdump, the assumption that the boot CPU when booting
an UP
kernel is always the CPU with a particular hardware ID (often 0)
(usually
referred to as BSP on some architectures) is not valid anymore. The
reason being that the dump capture kernel boots on the crashed CPU (the
CPU
* Daniel Walker [EMAIL PROTECTED] wrote:
Index: linux-2.6.20/include/linux/serial_core.h
===
--- linux-2.6.20.orig/include/linux/serial_core.h
+++ linux-2.6.20/include/linux/serial_core.h
@@ -213,7 +213,11 @@ struct uart_icount
On Tue, Apr 03, 2007 at 04:09:08PM -0700, Brad Boyer wrote:
The availability of the specific chip in question is a red herring in
my opinion. I do understand that 8250 compatible chips are very common
and are the most likely serial chips to be used with Linux. However, I
will point out that
Peter Zijlstra wrote:
On Wed, 2007-04-04 at 12:22 +1000, Nick Piggin wrote:
Eric Dumazet wrote:
I do think such workloads might benefit from a vma_cache not shared by
all threads but private to each thread. A sequence could invalidate the
cache(s).
ie instead of a mm-mmap_cache, having
hard_smp_processor_id used to be just a macro that hard-coded
hard_smp_processor_id to 0 in the non SMP case. When booting non SMP
kernels on hardware where the boot ioapic id is not 0 this turns out to
be a problem. This is happens frequently in the case of kdump and once
in a great while in
hard_smp_processor_id used to be just a macro that hard-coded
hard_smp_processor_id to 0 in the non SMP case. When booting non SMP
kernels on hardware where the boot ioapic id is not 0 this turns out to
be a problem. This is happens frequently in the case of kdump and once
in a great while in
On Wed, Apr 04, 2007 at 01:43:30AM -0700, David Miller wrote:
From: Russell King [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 09:38:03 +0100
However, despite people pressing for it, there's yet to be a *sane*
*technical* *solution* to the problem. All I've seen so far is one
bad hack.
On Wed, 2007-04-04 at 17:56 +0900, Fernando Luis Vázquez Cao wrote:
hard_smp_processor_id used to be just a macro that hard-coded
hard_smp_processor_id to 0 in the non SMP case. When booting non SMP
kernels on hardware where the boot ioapic id is not 0 this turns out to
be a problem. This is
Always ask the hardware to determine the hardware processor id in both
UP and SMP kernels.
Signed-off-by: Fernando Luis Vazquez Cao [EMAIL PROTECTED]
---
diff -urNp linux-2.6.21-rc5-orig/include/asm-ia64/smp.h
linux-2.6.21-rc5/include/asm-ia64/smp.h
---
The latest feature release GIT 1.5.1 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.1.tar.{gz,bz2}(tarball)
git-htmldocs-1.5.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.1.tar.{gz,bz2}
On Wed, Apr 04, 2007 at 06:55:18PM +1000, Nick Piggin wrote:
+ rcu_read_lock();
+ do {
+ t-vma_cache_sequence = -1;
+ t = next_thread(t);
+ } while (t != curr);
+ rcu_read_unlock();
On Tue, 3 Apr 2007, Andrew Morton wrote:
All of which indicates that if we can remove the down_write(mmap_sem) from
this glibc operation, things should get a lot better - there will be no
additional context switches at all.
And we can surely do that if all we're doing is looking up
Provide scalable per backing_dev_info statistics counters modeled on the ZVC
code.
Why do we need global_bdi_stat()? It should give approximately the
same numbers as global_page_state(), no?
Thanks,
Miklos
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
William Lee Irwin III wrote:
On Wed, Apr 04, 2007 at 06:55:18PM +1000, Nick Piggin wrote:
+ rcu_read_lock();
+ do {
+ t-vma_cache_sequence = -1;
+ t = next_thread(t);
+ } while (t != curr);
+
On Wed, 2007-04-04 at 11:20 +0200, Miklos Szeredi wrote:
Provide scalable per backing_dev_info statistics counters modeled on the ZVC
code.
Why do we need global_bdi_stat()? It should give approximately the
same numbers as global_page_state(), no?
For those counters that are shared, yes.
Andi Kleen wrote:
What do the benchmarks say with CONFIG_PARAVIRT on native hardware
compared to !CONFIG_PARAVIRT. e.g. does lmbench suffer?
Barely. There's a slight hit for not using patching, and patching is
almost identical to native performance. The most noticeable difference
is in the
On 04/03, Andrew Morton wrote:
On Tue, 03 Apr 2007 16:00:50 -0700
Ulrich Drepper [EMAIL PROTECTED] wrote:
If there is possibility to treat this case special and make it faster,
please do so. It would be best to allow pid==0 as a special case so
that callers don't have to find out the
On Wed, 04 Apr 2007 18:55:18 +1000
Nick Piggin [EMAIL PROTECTED] wrote:
Peter Zijlstra wrote:
On Wed, 2007-04-04 at 12:22 +1000, Nick Piggin wrote:
Eric Dumazet wrote:
I do think such workloads might benefit from a vma_cache not shared by
all threads but private to each thread. A
Scale writeback cache per backing device, proportional to its writeout speed.
akpm sayeth:
Which problem are we trying to solve here? afaik our two uppermost
problems are:
a) Heavy write to queue A causes light writer to queue B to blok for a long
time in balance_dirty_pages().
* Oleg Nesterov [EMAIL PROTECTED] wrote:
But we don't need tasklist_lock at all, we can use
rcu_read_lock/unlock. Q: don't we need task_rq_lock() to read
-cpus_allowed atomically ?
right now -cpus_allowed is protected by tasklist_lock. We cannot do RCU
here because -cpus_allowed
* Ingo Molnar [EMAIL PROTECTED] wrote:
could you try rt11 (which fixes two bad bugs in rt10)? If rt11 freezes
too then could you try to unapply the attached patch? This patch is
the main delta between rt5 and rt11. (plus upstream changes but those
shouldnt matter for this problem)
FYI,
Eric Dumazet wrote:
On Wed, 04 Apr 2007 18:55:18 +1000
Nick Piggin [EMAIL PROTECTED] wrote:
Peter Zijlstra wrote:
On Wed, 2007-04-04 at 12:22 +1000, Nick Piggin wrote:
Eric Dumazet wrote:
I do think such workloads might benefit from a vma_cache not shared by
all threads but private
On Wed, 4 Apr 2007, Russell King wrote:
On Tue, Apr 03, 2007 at 04:09:08PM -0700, Brad Boyer wrote:
The availability of the specific chip in question is a red herring in
my opinion. I do understand that 8250 compatible chips are very common
and are the most likely serial chips to be used
On 04/04, Ingo Molnar wrote:
* Oleg Nesterov [EMAIL PROTECTED] wrote:
But we don't need tasklist_lock at all, we can use
rcu_read_lock/unlock. Q: don't we need task_rq_lock() to read
-cpus_allowed atomically ?
right now -cpus_allowed is protected by tasklist_lock. We cannot do RCU
Russell King writes:
FACT: you can only have one struct console with one name.
That could be solved by having the struct console at the generic
serial driver level rather than in the individual port drivers.
FACT: there is no way to know at any particular driver registration time
how many
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
What do the benchmarks say with CONFIG_PARAVIRT on native hardware
compared to !CONFIG_PARAVIRT. e.g. does lmbench suffer?
Barely. There's a slight hit for not using patching, and patching is
almost identical to native performance. The
On Wed, 4 Apr 2007, Nick Piggin wrote:
On Fri, Mar 30, 2007 at 04:40:48AM +0200, Nick Piggin wrote:
Well it would make life easier if we got rid of ZERO_PAGE completely,
which I definitely wouldn't complain about ;)
Yes, I love this approach too.
So, what bad things (apart from my
* Oleg Nesterov [EMAIL PROTECTED] wrote:
On 04/04, Ingo Molnar wrote:
* Oleg Nesterov [EMAIL PROTECTED] wrote:
But we don't need tasklist_lock at all, we can use
rcu_read_lock/unlock. Q: don't we need task_rq_lock() to read
-cpus_allowed atomically ?
right now
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Rafael has already sent out the fix for that, but for some reason I
don't see it in the -mm.
With that fix, freezer and hence hotplug succeeds even when I am
running a 'make -j' test.
nice!
Good to know that!
So Ingo/Rafael, should
Eric Dumazet wrote:
Well, I believe this one is too expensive. I was thinking of a light one :
This one seems worse. Passing your vm_area_cache around everywhere, which
is just intrusive and dangerous because ot becomes decoupled from the mm
struct you are passing around. Watch this:
@@
* Andrew Morton [EMAIL PROTECTED] wrote:
urgh, I screwed up, sorry.
utrace-prep-2 reverts a bit of the underlying tree so that the utrace
patches (which are against mainline) don't throw a tremendous reject
which has to be fixed each time I pull Roland's tree. I'm supposed to
reapply
On Wednesday 04 April 2007 05:55:04 you wrote:
please check the patch
config X86_64_ACPI_NUMA
bool ACPI NUMA detection
depends on NUMA
select ACPI
select PCI
select ACPI_NUMA
default y
help
Enable ACPI SRAT based node topology
On Wed, 2007-04-04 at 11:34 +0200, Miklos Szeredi wrote:
Scale writeback cache per backing device, proportional to its writeout
speed.
akpm sayeth:
Which problem are we trying to solve here? afaik our two uppermost
problems are:
a) Heavy write to queue A causes light writer
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
- if (!(flags MAP_SHARED))
+ /* Deal with MAP_FIXED differently ? Forbid it ? Need help from some
nommu
+ * folks there... --BenH.
+ */
+ if ((flags MAP_FIXED) || !(flags MAP_SHARED))
MAP_FIXED on NOMMU? Surely you
What kind of applications are we talking about here? I'd like to hack
hardware I own.
payment systems, EMV terminals, mobile phone applications
Tasos Parisinos
-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
arch/blackfin/Kconfig |8
arch/blackfin/kernel/vmlinux.lds.S |8
include/asm-blackfin/cache.h | 11 +++
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/blackfin/Kconfig
On Wed, Apr 04, 2007 at 10:45:39AM +0100, Hugh Dickins wrote:
On Wed, 4 Apr 2007, Nick Piggin wrote:
On Fri, Mar 30, 2007 at 04:40:48AM +0200, Nick Piggin wrote:
Well it would make life easier if we got rid of ZERO_PAGE completely,
which I definitely wouldn't complain about ;)
Yes,
I'm worried about two things:
1) If the per-bdi threshold becomes smaller than the granularity of
the per-bdi stat (due to the per-CPU counters), then things will
break. Shouldn't there be some sanity checking for the calculated
threshold?
I'm not sure what you're
601 - 700 of 1202 matches
Mail list logo
