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.
> > The built-in ports can generally be enumerated early on boot in a
> > stable order, and they should be assigned the low ttySn numbers,
> >
Matt Mackall wrote:
On Wed, Apr 04, 2007 at 01:51:37PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
I think it would be better in mm/.
I originally was looking at putting it in
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 ports. There's only one or two drivers which
Alan Cox wrote:
Nothing terribly exciting here just odd glitches from the merge
ACK, will apply if I can sort out the confusion between -mm and local
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
H. Peter Anvin a écrit :
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor
On Wed, 4 Apr 2007 00:33:36 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> This is an old bug. It has been happening forever, but I'd love to
> know how I can help get this tracked down and fixed.
Yes, I've been hitting something like that in the past 3-4 weeks. We
started to diagnose it but
On Tue, 2007-04-03 at 17:37 +0200, Martin Mares wrote:
> Hello!
>
> > 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
> >
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
having a
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor modifies data within 2k of
On Tue, 2007-04-03 at 17:35 +0100, Paul LeoNerd Evans wrote:
> On Tue, Apr 03, 2007 at 04:20:52PM +, Pavel Machek wrote:
> > HPA is right... this should be fixed in userland. Reset should reset a
> > console, and if you want utf-8, do \ec\ewhatever to get it.
>
> As I've already said
This is an old bug. It has been happening forever, but I'd love to
know how I can help get this tracked down and fixed.
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV
H. Peter Anvin a écrit :
Eric Dumazet wrote:
There is one thing that always worried me.
Intel & AMD manuals make clear that mixing data and program in the
same page is bad for performance.
In particular, x86_64 vsyscall put jiffies and other
vsyscall_gtod_data_t right in the midle of
On Wed, Apr 04, 2007 at 01:51:37PM +1000, Nick Piggin wrote:
> Matt Mackall wrote:
> >Move the page walker code to lib/
> >
> >This lets it get shared outside of proc/ and linked in only when
> >needed.
>
> I think it would be better in mm/.
I originally was looking at putting it in mm/memory.c
H. Peter Anvin wrote:
> Mutable data should be separated from code. I think any current CPU
> will do fine as long as they are in separate 128-byte chunks, but they
> need at least that much separation.
P4 manual says that if one processor modifies data within 2k of another
processor executing
On Wed, 2007-04-04 at 14:20 +1000, Paul Mackerras wrote:
> I never suggested *all* serial ports should be /dev/ttySn, I said that
> the built-in ports on the motherboard should be /dev/ttySn.
Why? What's so special about the name 'ttyS'?
> The built-in ports can generally be enumerated early
Eric Dumazet wrote:
There is one thing that always worried me.
Intel & AMD manuals make clear that mixing data and program in the same
page is bad for performance.
In particular, x86_64 vsyscall put jiffies and other
vsyscall_gtod_data_t right in the midle of code. That is certainly not
H. Peter Anvin a écrit :
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Sounds like it would need a device which can be waited upon for changes.
A vdso-like shared page could have a futex in it.
Yes, but a futex couldn't be waited upon with a bunch of other things as
part of a poll or a
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 above mail didnt make it into lkml (maybe it
exceeded the
Jan Engelhardt a écrit :
On Apr 2 2007 12:41, Eric Dumazet wrote:
The following patch does the right thing for pipes, I let you doing
the same for sockets...
Is struct sock->sk_receive_queue->qlen actually the thing I am
looking for? (Previously, I had struct sock->sk_rcvbuf, which was
On Sun, Apr 01, 2007 at 01:06:46PM +0530, Milind Arun Choudhary wrote:
> ROUND_UP macro cleanup, use ALIGN where ever appropriate
>
> Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]>
Also looks good to me. Just one white space nit we can fixup by hand.
Signed-off-by: Grant Grundler
Don't know if this got reported yet. It's slightly stale
(against 2.6.21-rc4-git6), but I don't recall seeing
anything in the changelogs recently that would make this
irrelevant.
Dave
--
http://www.codemonkey.org.uk
--- Begin Message ---
Please do not reply directly to this email. All
On Sat, Mar 31, 2007 at 04:27:46PM +0530, Milind Arun Choudhary wrote:
> Clean up ROUND_?UP, Use ALIGN where ever appropriate.
>
> Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]>
Milind,
Looks good to me.
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
Kyle,
can you remind me how
Alan Cox writes:
> That would be completely unmanagable on many systems with multiport
> controllers and interfaces where the naming tells you things like which
> cable port off which socket off which multiplexor is the one you are
> talking about.
I never suggested *all* serial ports should be
On Mon, 2007-04-02 at 00:31 -0400, Dave Dillow wrote:
> On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
[snipped for brevity]
> > [EMAIL PROTECTED] music]# stat .
> > Device: fd00h/64768dInode: 10354963Links: 39
> > Now rebooted to 2.6.21-rc5:
> > Device: ee00h/60928dInode:
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm/hugetlbpage.c |8
2 files changed, 15 insertions(+)
Index: linux-cell/arch/ia64/kernel/sys_ia64.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/i386/mm/hugetlbpage.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
---
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
===
---
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
---
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
---
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
This is a "first step" as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
The current get_unmapped_area code calls the f_ops->get_unmapped_area or
the arch one (via
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
---
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/i386/mm/hugetlbpage.c
resend
On 4/3/07, Yinghai Lu <[EMAIL PROTECTED]> wrote:
please check the patch
YH
[PATCH] x86_64/acpi: make kernel to be compiled when CONFIG_ACPI_NUMA is set and power management with acpi is not enabled
when CONFIG_ACPI_NUMA is set, and power management with acpi is not used. the kernel
On Wed, 2007-04-04 at 14:01 +1000, Benjamin Herrenschmidt wrote:
> This is a "first step" as there are still cleanups to be done in various
> areas touched by that code but I think it's probably good to go as is and
> at least enables me to implement what I need for PowerPC.
.../...
And sorry
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
===
---
On 4/3/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
User space queries like "what is the cpuset to which this task belongs",
where the answer needs to be something of the form "/dev/cpuset/C1"?
The patches address that requirement atm by having a dentry pointer in
struct cpuset itself.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm/hugetlbpage.c |8
2 files changed, 15 insertions(+)
Index: linux-cell/arch/ia64/kernel/sys_ia64.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
---
This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
and change the caller now that everybody can handle it.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
mm/mmap.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
Index: linux-cell/mm/mmap.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
---
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
mm/mmap.c | 16
1 file changed, 16 deletions(-)
Index: linux-cell/mm/mmap.c
===
--- linux-cell.orig/mm/mmap.c 2007-03-22 16:30:24.0 +1100
Hi Yoichi,
Could you please try the patch below? It moves platform device creation
code into cobalt arch code to belletr follow driver model.
Thank you!
--
Dmitry
Input: cobalt buttons - separate device and driver registration
Create platform device for cobalt buttons as part of arch setup.
This is a "first step" as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
The current get_unmapped_area code calls the f_ops->get_unmapped_area or
the arch one (via
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/b44.c |2 +-
drivers/net/cxgb3/common.h|9 +--
drivers/net/cxgb3/cxgb3_main.c|
please check the patch
YH
[PATCH] x86_64/acpi: make kernel to be compiled when CONFIG_ACPI_NUMA is set and power management with acpi is not enabled
when CONFIG_ACPI_NUMA is set, and power management with acpi is not used. the kernel can not be compiled.
drivers/acpi/bus.c: In function
Matt Mackall wrote:
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
I think it would be better in mm/.
So would clear_refs_pte_range, and clear_refs_write (in a more
generic form), IMO.
Sweet patchset, though.
--
SUSE Labs, Novell
On Tue, 03 Apr 2007, Jeremy Fitzhardinge wrote:
> Attached. Is there some tool for decoding the DSDT?
iasl. The documentation is the ACPI Specification.
> >> ezr:pts/1; cat /proc/acpi/ibm/thermal
> >> temperatures: 72 55 -128 65 40 -128 35 -128 51 53 -128 -128 -128 -128
> >> -128 -128
> >
>
vatsa wrote:
> User space queries like "what is the cpuset to which this task belongs",
> where the answer needs to be something of the form "/dev/cpuset/C1"?
I think that answer should be of the form "/C1", and not include the
cpuset file system mount point ... though for the purposes of the
[EMAIL PROTECTED] wrote:
On Tue, 03 Apr 2007 19:20:04 PDT, Randy Dunlap said:
On Tue, 03 Apr 2007 21:35:54 -0400 [EMAIL PROTECTED] wrote:
I do a '/ACPI_SLEEP' inside that, and I get this output:
x Symbol: ACPI_SLEEP [=n] x
x Depends on:
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 ;)
So, what bad things (apart from my bugs in untested code) happen
if we do this? We can actually go further, and
On Tue, 03 Apr 2007 19:20:04 PDT, Randy Dunlap said:
> On Tue, 03 Apr 2007 21:35:54 -0400 [EMAIL PROTECTED] wrote:
> > I do a '/ACPI_SLEEP' inside that, and I get this output:
> >
> > x Symbol: ACPI_SLEEP [=n] x
> > x Depends on: !X86_NUMAQ &&
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section mismatch warnings in mtrr code.
Fix line length on one source line.
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to
.init.data: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x103)
WARNING:
On Wed, 04 Apr 2007 12:28:38 +1000 Rusty Russell wrote:
> lguest wants range checking, but unless there are other users I'm not
> sure this is worth the pain. Putting it out there in case it's useful.
>
> Cheers,
> Rusty.
> ==
> There are some places where we want to check if a value + length
On Wed, 4 Apr 2007, Alan Cox wrote:
> You don't get machines with 64 ethernet ports on add-in cards. There are
> good reasons for the naming schemes in use.
If they made them I'd build one.
http://innerfire.net/pics/projects/21portfirewall_2.jpg
Gerhard
--
Gerhard Mack
[EMAIL
On Tue, Apr 03, 2007 at 07:45:16PM +0530, Gautham R Shenoy wrote:
> > Should we ignore this for the timebeing and take up later as and when
> > users report problems?
>
> In my case, the problem of freezer failing was due to the vfork freezer race
> in do_fork. The parent task was
Ulrich wrote:
> For sysconf() we still need better support. Maybe now somebody will
> step up and say they need faster sysconf as well.
That won't be me ;).
For any kernel compiled with CONFIG_CPUSETS (which includes the major
distros I am aware of), one can just count the bits in the top
On Tue, Apr 03, 2007 at 10:49:49AM -0700, Paul Menage wrote:
> > Why is the hierarchy bit important here? Usually controllers need to
> > know "tell me what cpuset this task belongs to", which is answered
> > by tsk->nsproxy->ctlr_data[CPUSET_ID].
>
> I was thinking of queries from userspace.
Ulrich wrote:
> But all this of course does not solve the issue sysconf() has. In
> sysconf we cannot use sched_getaffinity since all the systems CPUs must
> be reported.
Good point. Yes, sysconf(_SC_NPROCESSORS_CONF) really needs to continue
returning the number of CPUs online, to maintain
Marko Macek wrote:
Ulrich Drepper wrote:
A solution for this problem is a madvise() operation with the following
property:
- the content of the address range can be discarded
- if an access to a page in the range happens in the future it must
succeed. The old page content can be
Andrew wrote:
> > But all this of course does not solve the issue sysconf() has. In
> > sysconf we cannot use sched_getaffinity since all the systems CPUs must
> > be reported.
>
> OK.
>
> This is excecptionally gruesome, but one could run sched_getaffinity()
> against pid 1 (init). Which will
Ulrich Drepper wrote:
A solution for this problem is a madvise() operation with the following
property:
- the content of the address range can be discarded
- if an access to a page in the range happens in the future it must
succeed. The old page content can be provided or a new, empty
Andrew wrote:
> Paul, could you please describe what cpusets' policy is in the presence of
> CPU additional and removal?
Currently, if we remove the last CPU in a cpuset, we give that cpuset
the CPUs of its parent cpuset, in order to ensure that every cpuset
with tasks attached actually has some
Hi Karl,
On Tuesday 03 April 2007 20:34, Karl Pickett wrote:
> 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
Move clear_refs code to task_mmu.c
This puts all the clear_refs code where it belongs and probably lets
things compile on MMU-less systems as well.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/base.c
===
---
Regroup task_mmu by interface
Reorder source so that all the code and data for each interface is
together.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-28
Simplify interdependence of /proc/pid/maps and smaps
This pulls the shared map display code out of show_map and puts it in
show_smap where it belongs.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-27
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: Matt Mackall <[EMAIL PROTECTED]>
Index:
Remove vma from args in the page walker
This makes the walker more generic.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-24 21:33:50.0 -0500
+++
Make /proc/pid/smaps optional 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/clear_refs, this save a few K.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index:
Add /proc/kpagemap interface
This makes physical page flags and counts available to userspace.
Together with /proc/pid/pagemap and /proc/pid/clear_refs, this can be
used to measure memory usage on a per-page basis.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/proc_misc.c
Add /proc/pid/pagemap interface
This interface provides a mapping for each page in an address space to
its physical page frame number, allowing precise determination of what
pages are mapped and what pages are shared between processes.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index:
Eliminate the pmd_walker struct in the page walker
This slightly simplifies things for the next few cleanups.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c
Uninline some functions in the page walker
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-24 21:33:42.0 -0500
+++ mm/fs/proc/task_mmu.c
Propagate errors from callback in page walker
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-24 21:33:52.0 -0500
+++ mm/fs/proc/task_mmu.c
Add callbacks for each level to page walker
This allows iterating over all levels of the page tables. Recursion
continues to the depth of the lowest supplied callback.
This makes the page walker nearly completely generic and should allow
it to replace some other hand-rolled page table walkers.
This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
which allow detailed run-time examination of process memory usage at a
page granularity.
The first several patches whip the page-walking code introduced for
/proc/pid/smaps and clear_refs into a more generic form, the next
couple
Adrian Bunk wrote:
On Fri, Mar 30, 2007 at 01:05:59AM -0700, Andrew Morton wrote:
...
Changes since 2.6.21-rc5-mm2:
...
git-netdev-all.patch
...
git trees
...
This patch makes the needlessly global PHY_DEVICES[] static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
BTW: Why is the
[EMAIL PROTECTED] wrote:
From: Divy Le Ray <[EMAIL PROTECTED]>
Ensure that the TCAM active region size is at least 16.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h|3 +++
drivers/net/cxgb3/cxgb3_main.c|7 +--
lguest wants range checking, but unless there are other users I'm not
sure this is worth the pain. Putting it out there in case it's useful.
Cheers,
Rusty.
==
There are some places where we want to check if a value + length is
within a range. This can be tricky, so it's nice to have a single
On Tue, 3 Apr 2007, [EMAIL PROTECTED] wrote:
On Tue, 03 Apr 2007 16:09:08 PDT, Brad Boyer said:
an abstraction of "serial port" as far as the user is concerned. On
Solaris, I can say "/dev/term/a" and know that I will get the first
serial port if it is available without needing to care if it
Eric Dumazet wrote:
Andrew Morton a écrit :
On Tue, 3 Apr 2007 16:29:37 -0400
Jakub Jelinek <[EMAIL PROTECTED]> wrote:
On Tue, Apr 03, 2007 at 01:17:09PM -0700, Ulrich Drepper wrote:
Andrew Morton wrote:
Ulrich, could you suggest a little test app which would demonstrate
this
behaviour?
On Tue, 03 Apr 2007 21:35:54 -0400 [EMAIL PROTECTED] wrote:
> On Mon, 02 Apr 2007 22:47:45 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/
>
> So I was looking at a patch for ACPI_SLEEP that went around a moment ago,
> and
Once upon a time, Brad Boyer <[EMAIL PROTECTED]> said:
>The point is that people are used to having "ttyS0" mean the first
>onboard serial port.
My first serial port is a USB dongle and is ttyUSB0. If the argument is
that all serials should be ttyS[0-9]+, are you going to change USB
adapters as
On Tue, 03 Apr 2007 16:09:08 PDT, Brad Boyer said:
> an abstraction of "serial port" as far as the user is concerned. On
> Solaris, I can say "/dev/term/a" and know that I will get the first
> serial port if it is available without needing to care if it is the
> zs, se or asy driver talking to
On 04/03/2007 08:32 PM, Pekka J Enberg wrote:
Please enable CONFIG_DEBUG_SLAB now and reproduce. It should tell us
what's going wrong there.
Taking forever to reproduce in as far as getting the oops. The thing is
now just locking hard each time. Will keep on trying...
Rene.
-
To
Paa Paa wrote:
Q: What conclusion can I make on "hdparm -t" results or can I make
any conclusions? Do I really have lower performance with NCQ or not?
If I do, is this because of my HD or because of kernel?
What IO scheduler are you using? If AS or CFQ, could you try with
deadline?
I was
1 - 100 of 934 matches
Mail list logo
