Re: [2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node.

2008-02-05 Thread KOSAKI Motohiro
Hi Paul > Hopefully this week or next, I will publish this patch proposal. Great. at that time, I will join review the patch with presure :) - kosaki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info

[2.6.24 regression][BUGFIX] numactl --interleave=all doesn't works on memoryless node.

2008-02-05 Thread KOSAKI Motohiro
e memory. This is one of > the memoryless nodes fixes. I THINK this is one of the areas that Paul > and David are investigating. this is good news for me :) I'll wait his patch post. Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- mm/mempolicy.c | 11 +++ 1 file c

[2.6.24 regression][BUGFIX] numactl --interleave=all doesn't works on memoryless node.

2008-02-05 Thread KOSAKI Motohiro
his patch post. Signed-off-by: KOSAKI Motohiro [EMAIL PROTECTED] --- mm/mempolicy.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Index: b/mm/mempolicy.c === --- a/mm/mempolicy.c2008-02-02 17:54

Re: [2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node.

2008-02-05 Thread KOSAKI Motohiro
Hi Paul Hopefully this week or next, I will publish this patch proposal. Great. at that time, I will join review the patch with presure :) - kosaki -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH] badness() dramatically overcounts memory

2008-02-05 Thread KOSAKI Motohiro
Hi The interesting thing is the use of total_vm and not the RSS which is used as the basis by the OOM killer. I need to read/understand the code a bit more. RSS makes more sense to me as well. Andrea Arcangeli has patches pending which change this to the RSS.

Re: [2.6.24 regression][BUGFIX] numactl --interleave=all doesn't works on memoryless node.

2008-02-05 Thread KOSAKI Motohiro
Hi Lee-san Here's a patch that addresses the problem w/o requiring change to numactl or libnuma. It DOES have side affects, discussed in the description. Thank you! but unfortunately, My machine is broken phisically today ;-) I will test it tommorow or later. -- To unsubscribe from this

Re: [RFC] Parallelize IO for e2fsck

2008-02-03 Thread KOSAKI Motohiro
Hi Pavel > > > As user pages are always in highmem, this should be easy to decide: > > > only send SIGDANGER when highmem is full. (Yes, there are > > > inodes/dentries/file descriptors in lowmem, but I doubt apps will > > > respond to SIGDANGER by closing files). > > > > Good point; for a system

Re: Kernel Event Notifications (was: [RFC] Parallelize IO for e2fsck)

2008-02-03 Thread KOSAKI Motohiro
Hi Jon > I looked at this a year or two back, then ran out of time. But the thing > I wanted to do was have libc's memory allocation routines extended to > handle these through reservations - the kernel should send a userspace > notification and then there should be some kind of concept of

Re: Kernel Event Notifications (was: [RFC] Parallelize IO for e2fsck)

2008-02-03 Thread KOSAKI Motohiro
Hi Jon I looked at this a year or two back, then ran out of time. But the thing I wanted to do was have libc's memory allocation routines extended to handle these through reservations - the kernel should send a userspace notification and then there should be some kind of concept of returning

Re: [RFC] Parallelize IO for e2fsck

2008-02-03 Thread KOSAKI Motohiro
Hi Pavel As user pages are always in highmem, this should be easy to decide: only send SIGDANGER when highmem is full. (Yes, there are inodes/dentries/file descriptors in lowmem, but I doubt apps will respond to SIGDANGER by closing files). Good point; for a system with at least

Re: [2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node.

2008-02-02 Thread KOSAKI Motohiro
ocess should check has_high_memory file. but, I am not confident. Thanks. - kosaki Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- drivers/base/node.c |7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) Index: b/drivers/base/node.c

[2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node.

2008-02-02 Thread KOSAKI Motohiro
Hi I tested numactl on 2.6.24-rc8-mm1. and I found strange behavior. test method and result. $ numactl --interleave=all ls set_mempolicy: Invalid argument setting interleave mask: Invalid argument numactl command download from

[2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node.

2008-02-02 Thread KOSAKI Motohiro
Hi I tested numactl on 2.6.24-rc8-mm1. and I found strange behavior. test method and result. $ numactl --interleave=all ls set_mempolicy: Invalid argument setting interleave mask: Invalid argument numactl command download from

Re: [2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node.

2008-02-02 Thread KOSAKI Motohiro
that has_high_memory exposed however CONFIG_HIGHMEM disabled. if CONFIG_HIGHMEM disabled, the has_high_memory file show the same as the has_normal_memory. may be, userland process should check has_high_memory file. but, I am not confident. Thanks. - kosaki Signed-off-by: KOSAKI Motohiro [EMAIL PROTECTED

Re: [patch 05/19] split LRU lists into anon & file sets

2008-01-31 Thread KOSAKI Motohiro
> I will integrate your fixes with my code when I > get back from holidays. Then things should work :) > > Thank you for your analysis of the problem. Thank you. enjoy good vacation :) - kosaki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [patch 05/19] split LRU lists into anon file sets

2008-01-31 Thread KOSAKI Motohiro
I will integrate your fixes with my code when I get back from holidays. Then things should work :) Thank you for your analysis of the problem. Thank you. enjoy good vacation :) - kosaki -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to

Re: [patch 05/19] split LRU lists into anon & file sets

2008-01-30 Thread KOSAKI Motohiro
Hi Lee-san > Rik is currently out on holiday and I've been traveling. Just getting > back to rebasing to 24-rc8-mm1. Thank you for your efforts in testing > and tracking down the regressions. I will add your fixes into my tree > and try them out and let you know. Rik mentioned to me that he

Re: [patch 05/19] split LRU lists into anon & file sets

2008-01-30 Thread KOSAKI Motohiro
- kosaki Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- mm/vmscan.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) Index: b/mm/vmscan.c === --- a/mm/vmscan.c 2008-01-30 15:22:10.00

Re: [patch 05/19] split LRU lists into anon file sets

2008-01-30 Thread KOSAKI Motohiro
Signed-off-by: KOSAKI Motohiro [EMAIL PROTECTED] --- mm/vmscan.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) Index: b/mm/vmscan.c === --- a/mm/vmscan.c 2008-01-30 15:22:10.0 +0900 +++ b/mm/vmscan.c

Re: [patch 05/19] split LRU lists into anon file sets

2008-01-30 Thread KOSAKI Motohiro
Hi Lee-san Rik is currently out on holiday and I've been traveling. Just getting back to rebasing to 24-rc8-mm1. Thank you for your efforts in testing and tracking down the regressions. I will add your fixes into my tree and try them out and let you know. Rik mentioned to me that he has a

Re: [patch 05/19] split LRU lists into anon & file sets

2008-01-29 Thread KOSAKI Motohiro
eed reintroduce this portion after new page LRU (aka LRU for used only page). but now is too early. I hope this patch series merge to -mm ASAP. therefore, I hope remove any corner case regression. Thanks! - kosaki Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- mm/vmscan

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-28 Thread KOSAKI Motohiro
> here's a QuickStart: > >http://redhat.com/~mingo/x86.git/README Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-28 Thread KOSAKI Motohiro
here's a QuickStart: http://redhat.com/~mingo/x86.git/README Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at

Re: [PATCH] [14/18] BKL-removal: Add unlocked_fasync

2008-01-26 Thread KOSAKI Motohiro
> Add a new fops entry point to allow fasync without BKL. While it's arguably > unclear this entry point is called often enough for it really matters > it was still relatively easy to do. And there are far less async users > in the tree than ioctls so it's likely they can be all converted >

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-26 Thread KOSAKI Motohiro
Hi Mel > > my patch stack is > > 2.6.24-rc7 + > > http://lkml.org/lkml/2007/8/24/220 + > > Can you replace this patch with the patch below instead and try again > please? This is the patch that is actually in git-x86. Out of > curiousity, have you tried the latest mm branch from git-x86? to

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-26 Thread KOSAKI Motohiro
> 1. if sparce_mem on, build failture after fix compile error, no panic and bad-page happened both highmem off and 64G. I guess discontigmem numa is premature yet ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More

Re: Kernel Event Notifications (was: [RFC] Parallelize IO for e2fsck)

2008-01-26 Thread KOSAKI Motohiro
Hi Al > > the mem_notify patch can realize "just before starting swapping" > > notification :) > > > > to be honest, I don't know fs guys requirement. > > if lacking feature of fs guys needed, I implement it with presure if > > you tell me it. > > These notifications are really useful, but it may

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-26 Thread KOSAKI Motohiro
Hi Mel >To rule it out, can you also try with the patch below applied please? It >should only make a difference on sparsemem so if discontigmem is still >crashing, there is likely another problem. Assuming it crashes, please >post the full dmesg output with loglevel=8 on the command line. Thanks

Re: [RFC] Parallelize IO for e2fsck

2008-01-26 Thread KOSAKI Motohiro
> > And from a performance point of view letting applications voluntarily > > free some memory is better even than starting to swap. > > Absolutely. the mem_notify patch can realize "just before starting swapping" notification :) to be honest, I don't know fs guys requirement. if lacking feature

Re: [RFC] Parallelize IO for e2fsck

2008-01-26 Thread KOSAKI Motohiro
> The commentary on the mem_notify threads claimed that the signal is > easily provided by setting up the file handle for SIGIO. BTW: Of cource, you can receive any signal instead SIGIO by use fcntl(F_SETSIG) :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the

Re: [RFC] Parallelize IO for e2fsck

2008-01-26 Thread KOSAKI Motohiro
The commentary on the mem_notify threads claimed that the signal is easily provided by setting up the file handle for SIGIO. BTW: Of cource, you can receive any signal instead SIGIO by use fcntl(F_SETSIG) :-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [RFC] Parallelize IO for e2fsck

2008-01-26 Thread KOSAKI Motohiro
And from a performance point of view letting applications voluntarily free some memory is better even than starting to swap. Absolutely. the mem_notify patch can realize just before starting swapping notification :) to be honest, I don't know fs guys requirement. if lacking feature of fs

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-26 Thread KOSAKI Motohiro
Hi Mel To rule it out, can you also try with the patch below applied please? It should only make a difference on sparsemem so if discontigmem is still crashing, there is likely another problem. Assuming it crashes, please post the full dmesg output with loglevel=8 on the command line. Thanks I

Re: Kernel Event Notifications (was: [RFC] Parallelize IO for e2fsck)

2008-01-26 Thread KOSAKI Motohiro
Hi Al the mem_notify patch can realize just before starting swapping notification :) to be honest, I don't know fs guys requirement. if lacking feature of fs guys needed, I implement it with presure if you tell me it. These notifications are really useful, but it may be much wiser

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-26 Thread KOSAKI Motohiro
1. if sparce_mem on, build failture after fix compile error, no panic and bad-page happened both highmem off and 64G. I guess discontigmem numa is premature yet ;-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More

Re: [RFC][PATCH 3/8] mem_notify v5: introduce /dev/mem_notify new device (the core of this patch series)

2008-01-24 Thread KOSAKI Motohiro
Hi Daniel > > +#define PROC_WAKEUP_GUARD (10*HZ) > [...] > > + timeout = info->last_proc_notify + PROC_WAKEUP_GUARD; > > If only one or a few processes are using the system I think 10 seconds > is a little long time to wait before they get the notification again. > Can we decrease this

Re: [RFC][PATCH 3/8] mem_notify v5: introduce /dev/mem_notify new device (the core of this patch series)

2008-01-24 Thread KOSAKI Motohiro
Hi Daniel +#define PROC_WAKEUP_GUARD (10*HZ) [...] + timeout = info-last_proc_notify + PROC_WAKEUP_GUARD; If only one or a few processes are using the system I think 10 seconds is a little long time to wait before they get the notification again. Can we decrease this value? Or

[RFC][PATCH 8/8] mem_notify v5: support fasync feature

2008-01-23 Thread KOSAKI Motohiro
Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- mm/mem_notify.c | 95 +--- 1 file changed, 90 insertions(+), 5 deletions(-) Index: b/mm/mem_notify.c === --- a/mm/mem

[RFC][PATCH 6/8] mem_notify v5: (optional) fixed incorrect shrink_zone

2008-01-23 Thread KOSAKI Motohiro
on X86, ZONE_DMA is very very small. It is often no used at all. Unfortunately, when NR_ACTIVE==0, NR_INACTIVE==0, shrink_zone() try to reclaim 1 page. because zone->nr_scan_active += (zone_page_state(zone, NR_ACTIVE) >> priority) + 1;

[RFC][PATCH 7/8] mem_notify v5: ignore very small zone for prevent incorrect low mem notify.

2008-01-23 Thread KOSAKI Motohiro
-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- include/linux/mem_notify.h |3 +++ mm/page_alloc.c|6 +- 2 files changed, 8 insertions(+), 1 deletion(-) Index: b/include/linux/mem_notify.h === --- a/include

[RFC][PATCH 5/8] mem_notify v5: add new mem_notify field to /proc/zoneinfo

2008-01-23 Thread KOSAKI Motohiro
show new member of zone struct by /proc/zoneinfo. ChangeLog: v5: change display order to at last. Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- mm/vmstat.c |8 +--- 1 file changed, 5 insertions(+),

[RFC][PATCH 4/8] mem_notify v5: memory_pressure_notify() caller

2008-01-23 Thread KOSAKI Motohiro
pressure decrease and stop moves an anonymous page to the inactive list. o free pages increase than (pages_high+lowmem_reserve)*2. ChangeLog: v5: add out of trouble notify to exit of balance_pgdat(). Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> Signed-off-by: KOSAKI Motohiro &

[RFC][PATCH 3/8] mem_notify v5: introduce /dev/mem_notify new device (the core of this patch series)

2008-01-23 Thread KOSAKI Motohiro
s.revents = 0; err = poll(, 1, -1); // wake up at low memory ... Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- Documentation/devices.txt |1 drivers/char/mem.c |6 ++ include/

[RFC][PATCH 2/8] mem_notify v5: introduce wake_up_locked_nr() new API

2008-01-23 Thread KOSAKI Motohiro
introduce new API wake_up_locked_nr() and wake_up_locked_all(). it it similar as wake_up_nr() and wake_up_all(), but it doesn't lock. Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- include/linux/wait.h |7 +-- ke

[RFC][PATCH 1/8] mem_notify v5: introduce poll_wait_exclusive() new API

2008-01-23 Thread KOSAKI Motohiro
, _wait_queue, wait); if (data_exist) return POLLIN | POLLRDNORM; return 0; } Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- fs/eventpoll.c |7 +-- fs/select.c |9 ++--- i

[RFC][PATCH 0/8] mem_notify v5

2008-01-23 Thread KOSAKI Motohiro
[kosaki] http://marc.info/?l=linux-mm=120035840523718=2 Changelog - v4 -> v5 (by KOSAKI Motohiro) o rebase to 2.6.24-rc8-mm1 o change display order of /proc/zoneinfo o ignore very small zone o support fcntl(F_SETFL, FAS

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-23 Thread KOSAKI Motohiro
Hi > To rule it out, can you also try with the patch below applied please? It > should only make a difference on sparsemem so if discontigmem is still > crashing, there is likely another problem. Assuming it crashes, Aaah, sorry. I can't test again until next week. I repost at that time... >

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-23 Thread KOSAKI Motohiro
Hi To rule it out, can you also try with the patch below applied please? It should only make a difference on sparsemem so if discontigmem is still crashing, there is likely another problem. Assuming it crashes, Aaah, sorry. I can't test again until next week. I repost at that time...

[RFC][PATCH 0/8] mem_notify v5

2008-01-23 Thread KOSAKI Motohiro
notification v4 [kosaki] http://marc.info/?l=linux-mmm=120035840523718w=2 Changelog - v4 - v5 (by KOSAKI Motohiro) o rebase to 2.6.24-rc8-mm1 o change display order of /proc/zoneinfo o ignore very small zone o support fcntl(F_SETFL

[RFC][PATCH 1/8] mem_notify v5: introduce poll_wait_exclusive() new API

2008-01-23 Thread KOSAKI Motohiro
) { poll_wait_exclusive(file, kosaki_wait_queue, wait); if (data_exist) return POLLIN | POLLRDNORM; return 0; } Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED] Signed-off-by: KOSAKI Motohiro [EMAIL PROTECTED] --- fs/eventpoll.c |7 +-- fs/select.c |9

[RFC][PATCH 2/8] mem_notify v5: introduce wake_up_locked_nr() new API

2008-01-23 Thread KOSAKI Motohiro
introduce new API wake_up_locked_nr() and wake_up_locked_all(). it it similar as wake_up_nr() and wake_up_all(), but it doesn't lock. Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED] Signed-off-by: KOSAKI Motohiro [EMAIL PROTECTED] --- include/linux/wait.h |7 +-- kernel/sched.c

[RFC][PATCH 3/8] mem_notify v5: introduce /dev/mem_notify new device (the core of this patch series)

2008-01-23 Thread KOSAKI Motohiro
; pollfds.revents = 0; err = poll(pollfds, 1, -1); // wake up at low memory ... /usage example Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED] Signed-off-by: KOSAKI Motohiro [EMAIL PROTECTED] --- Documentation/devices.txt |1 drivers/char/mem.c |6 ++ include/linux

[RFC][PATCH 4/8] mem_notify v5: memory_pressure_notify() caller

2008-01-23 Thread KOSAKI Motohiro
pressure decrease and stop moves an anonymous page to the inactive list. o free pages increase than (pages_high+lowmem_reserve)*2. ChangeLog: v5: add out of trouble notify to exit of balance_pgdat(). Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED] Signed-off-by: KOSAKI Motohiro [EMAIL

[RFC][PATCH 5/8] mem_notify v5: add new mem_notify field to /proc/zoneinfo

2008-01-23 Thread KOSAKI Motohiro
show new member of zone struct by /proc/zoneinfo. ChangeLog: v5: change display order to at last. Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED] Signed-off-by: KOSAKI Motohiro [EMAIL PROTECTED] --- mm/vmstat.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) Index

[RFC][PATCH 6/8] mem_notify v5: (optional) fixed incorrect shrink_zone

2008-01-23 Thread KOSAKI Motohiro
on X86, ZONE_DMA is very very small. It is often no used at all. Unfortunately, when NR_ACTIVE==0, NR_INACTIVE==0, shrink_zone() try to reclaim 1 page. because zone-nr_scan_active += (zone_page_state(zone, NR_ACTIVE) priority) + 1;

[RFC][PATCH 7/8] mem_notify v5: ignore very small zone for prevent incorrect low mem notify.

2008-01-23 Thread KOSAKI Motohiro
-by: KOSAKI Motohiro [EMAIL PROTECTED] --- include/linux/mem_notify.h |3 +++ mm/page_alloc.c|6 +- 2 files changed, 8 insertions(+), 1 deletion(-) Index: b/include/linux/mem_notify.h === --- a/include/linux

[RFC][PATCH 8/8] mem_notify v5: support fasync feature

2008-01-23 Thread KOSAKI Motohiro
v5: new Signed-off-by: KOSAKI Motohiro [EMAIL PROTECTED] --- mm/mem_notify.c | 95 +--- 1 file changed, 90 insertions(+), 5 deletions(-) Index: b/mm/mem_notify.c

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-22 Thread KOSAKI Motohiro
Hi mel > Hi > > > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot > > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look > > at the restrictions on setting NUMA on x86 to see if they could be lifted. > > Interesting! > > I will test tomorrow.

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-22 Thread KOSAKI Motohiro
Hi mel Hi A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look at the restrictions on setting NUMA on x86 to see if they could be lifted. Interesting! I will test tomorrow. Hmm... It

Re: LatencyTOP infrastructure patch

2008-01-21 Thread KOSAKI Motohiro
Hi > +static void __sched > +account_global_scheduler_latency(struct task_struct *tsk, int usecs) > +{ > + int i; > + int firstnonnull = MAXLR + 1; > + > + if (!tsk->latency_reason.reason) > + return; > + > + /* skip kernel threads for now */ > + if (!tsk->mm) > +

Re: LatencyTOP infrastructure patch

2008-01-21 Thread KOSAKI Motohiro
Hi +static void __sched +account_global_scheduler_latency(struct task_struct *tsk, int usecs) +{ + int i; + int firstnonnull = MAXLR + 1; + + if (!tsk-latency_reason.reason) + return; + + /* skip kernel threads for now */ + if (!tsk-mm) +

Re: Development release 0.1 of the LatencyTOP tool

2008-01-20 Thread KOSAKI Motohiro
Hi > The Intel Open Source Technology Center is pleased to announce the > release of version 0.1 of LatencyTOP, a tool for developers to visualize > system latencies. Interesting. at least, I will use for fixed page lock contension :) if possible, I want some /proc/lock_stat feature. i.e.

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-20 Thread KOSAKI Motohiro
Hi > A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot > on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look > at the restrictions on setting NUMA on x86 to see if they could be lifted. Interesting! I will test tomorrow. I think this patch become

Re: Development release 0.1 of the LatencyTOP tool

2008-01-20 Thread KOSAKI Motohiro
Hi The Intel Open Source Technology Center is pleased to announce the release of version 0.1 of LatencyTOP, a tool for developers to visualize system latencies. Interesting. at least, I will use for fixed page lock contension :) if possible, I want some /proc/lock_stat feature. i.e.

Re: [PATCH 0/2] Relax restrictions on setting CONFIG_NUMA on x86

2008-01-20 Thread KOSAKI Motohiro
Hi A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look at the restrictions on setting NUMA on x86 to see if they could be lifted. Interesting! I will test tomorrow. I think this patch become easy

Re: [RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

2008-01-18 Thread KOSAKI Motohiro
Hi Andrew, > > > on X86, ZONE_DMA is very very small. > > > It is often no used at all. > > > > In that case page-reclaim is supposed to set all_unreclaimable and > > basically ignores the zone altogether until it looks like something might > > have changed. > > > > Is that code not working?

Re: [RFC][PATCH 4/5] memory_pressure_notify() caller

2008-01-18 Thread KOSAKI Motohiro
Hi! > > 1. I doubt ZONE_DMA, please shipment ignore zone_dma patch(below). > > Your patch above solves the problem I had with early notification. really!? I am really happy!! Thanks you. - kosaki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [RFC][PATCH 4/5] memory_pressure_notify() caller

2008-01-18 Thread KOSAKI Motohiro
Hi! 1. I doubt ZONE_DMA, please shipment ignore zone_dma patch(below). Your patch above solves the problem I had with early notification. really!? I am really happy!! Thanks you. - kosaki -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

2008-01-18 Thread KOSAKI Motohiro
Hi Andrew, on X86, ZONE_DMA is very very small. It is often no used at all. In that case page-reclaim is supposed to set all_unreclaimable and basically ignores the zone altogether until it looks like something might have changed. Is that code not working? (quite possible).

Re: [RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

2008-01-17 Thread KOSAKI Motohiro
Hi Andrew > > on X86, ZONE_DMA is very very small. > > It is often no used at all. > > In that case page-reclaim is supposed to set all_unreclaimable and > basically ignores the zone altogether until it looks like something might > have changed. > > Is that code not working? (quite possible).

[RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

2008-01-17 Thread KOSAKI Motohiro
this patch against: 2.6.24-rc6-mm1 Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- mm/vmscan.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) Index: b/mm/vmscan.c === --- a/mm/vmscan.c

Re: 2.6.24-rc7: memory leak?

2008-01-17 Thread KOSAKI Motohiro
Hi > > > Should all this cache usage not be counted towards the > > > 'Cached' entry in meminfo rather then getting counted as part of used > > > ram. > > > > Cached is only the page-cache, not all the other caches we have.. > > This someones confuses people, but one gets used to it. slabinfo

Re: 2.6.24-rc7: memory leak?

2008-01-17 Thread KOSAKI Motohiro
Hi Should all this cache usage not be counted towards the 'Cached' entry in meminfo rather then getting counted as part of used ram. Cached is only the page-cache, not all the other caches we have.. This someones confuses people, but one gets used to it. slabinfo allows one to

[RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

2008-01-17 Thread KOSAKI Motohiro
against: 2.6.24-rc6-mm1 Signed-off-by: KOSAKI Motohiro [EMAIL PROTECTED] --- mm/vmscan.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) Index: b/mm/vmscan.c === --- a/mm/vmscan.c 2008-01-18 14:18

Re: [RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

2008-01-17 Thread KOSAKI Motohiro
Hi Andrew on X86, ZONE_DMA is very very small. It is often no used at all. In that case page-reclaim is supposed to set all_unreclaimable and basically ignores the zone altogether until it looks like something might have changed. Is that code not working? (quite possible). please

Re: Bitops source problem

2008-01-16 Thread KOSAKI Motohiro
Hi > If that is indeed the source of your change_bit function then there is > a problem. However in my kernel tree there is a LOCK_PREFIX in the > definition of the atomic version. I don't have your exact source tree > handy, but on a local RHEL4 system, the LOCK_PREFIX is still there: > >

Re: [RFC][PATCH 4/5] memory_pressure_notify() caller

2008-01-16 Thread KOSAKI Motohiro
challenge. thanks. - kosaki Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> --- include/linux/mem_notify.h |3 +++ mm/page_alloc.c|6 +- 2 files changed, 8 insertions(+), 1 deletion(-) Index: linux-2.6.24-rc6-mm1-

Re: [RFC] mmaped copy too slow?

2008-01-16 Thread KOSAKI Motohiro
Hi > > One thing you could also try is to pass MAP_POPULATE to mmap so that the > > page tables are filled in at the time of the mmap, avoiding a lot of > > page faults later. > > > > OK, I will test your idea and report about tomorrow. > but I don't think page fault is major performance

Re: [RFC][PATCH 3/5] add /dev/mem_notify device

2008-01-16 Thread KOSAKI Motohiro
Hi > > I'd read mem_notify as "tell me when new memory is unplugged" or > > something. /dev/oom_notify? Plus, /dev/ names usually do not have "_" > > in them. > > I don't think we should use oom in the name, since the notification is > sent long before oom. OK, I don't change name. Of cource, I

Re: [RFC][PATCH 3/5] add /dev/mem_notify device

2008-01-16 Thread KOSAKI Motohiro
Hi I'd read mem_notify as tell me when new memory is unplugged or something. /dev/oom_notify? Plus, /dev/ names usually do not have _ in them. I don't think we should use oom in the name, since the notification is sent long before oom. OK, I don't change name. Of cource, I will change

Re: [RFC] mmaped copy too slow?

2008-01-16 Thread KOSAKI Motohiro
Hi One thing you could also try is to pass MAP_POPULATE to mmap so that the page tables are filled in at the time of the mmap, avoiding a lot of page faults later. OK, I will test your idea and report about tomorrow. but I don't think page fault is major performance impact. I got

Re: [RFC][PATCH 4/5] memory_pressure_notify() caller

2008-01-16 Thread KOSAKI Motohiro
-by: KOSAKI Motohiro [EMAIL PROTECTED] --- include/linux/mem_notify.h |3 +++ mm/page_alloc.c|6 +- 2 files changed, 8 insertions(+), 1 deletion(-) Index: linux-2.6.24-rc6-mm1-memnotify/include/linux/mem_notify.h

Re: Bitops source problem

2008-01-16 Thread KOSAKI Motohiro
Hi If that is indeed the source of your change_bit function then there is a problem. However in my kernel tree there is a LOCK_PREFIX in the definition of the atomic version. I don't have your exact source tree handy, but on a local RHEL4 system, the LOCK_PREFIX is still there: static

Re: [PATCH] rlim in proc//status (2nd rev.)

2008-01-15 Thread KOSAKI Motohiro
Hi Clifford, > +static inline char *task_rlim(struct task_struct *p, char *buffer) > +{ > + unsigned long flags; > + struct rlimit rlim[RLIM_NLIMITS]; > + int i; > + > + rcu_read_lock(); > + if (lock_task_sighand(p, )) { > + for (i=0; i +

rvr split LRU minor regression ?

2008-01-15 Thread KOSAKI Motohiro
Hi Rik I tested new hackbench on rvr split LRU patch. new hackbench URL is http://people.redhat.com/mingo/cfs-scheduler/tools/hackbench.c method of test (1) $ ./hackbench 150 process 1000 (2) # sync; echo 3 > /proc/sys/vm/drop_caches $ dd if=tmp10G of=/dev/null $ ./hackbench 150

Re: [RFC][PATCH 3/5] add /dev/mem_notify device

2008-01-15 Thread KOSAKI Motohiro
Hi Alan > > > It also appears there is no way to wait for memory shortages (processes > > > that can free memory easily) only for memory to start appearing. > > > > poll() with never timeout don't fill your requirement? > > to be honest, maybe I don't understand your afraid yet. sorry. > > My

Re: [RFC] mmaped copy too slow?

2008-01-15 Thread KOSAKI Motohiro
Hi Paulo > One thing you could also try is to pass MAP_POPULATE to mmap so that the > page tables are filled in at the time of the mmap, avoiding a lot of > page faults later. > > Just my 2 cents, OK, I will test your idea and report about tomorrow. but I don't think page fault is major

Re: [RFC][PATCH 3/5] add /dev/mem_notify device

2008-01-15 Thread KOSAKI Motohiro
Hi Pavel > > err = poll(, 1, -1); // wake up at low memory > > > > ... > > > > Nice, this is really needed for openmoko, zaurus, etc > > But this changelog needs to go into Documentation/... > > ...and /dev/mem_notify is really a bad name. /dev/memory_low? > /dev/oom? thank

Re: [RFC][PATCH 4/5] memory_pressure_notify() caller

2008-01-15 Thread KOSAKI Motohiro
Hi Daniel > > > The notification fires after only ~100 MB allocated, i.e., when page > > > reclaim is beginning to nag from page cache. Isn't this a bit early? > > > Repeating the test with swap enabled results in a notification after > > > ~600 MB allocated, which is more reasonable and just

Re: [RFC][PATCH 3/5] add /dev/mem_notify device

2008-01-15 Thread KOSAKI Motohiro
Hi Alan thank you for kindfull explain. > > > > the core of this patch series. > > > > add /dev/mem_notify device for notification low memory to user process. > > > > > > As you only wake one process how would you use this API from processes > > > which want to monitor and can free memory under

Re: [RFC][PATCH 3/5] add /dev/mem_notify device

2008-01-15 Thread KOSAKI Motohiro
> > the core of this patch series. > > add /dev/mem_notify device for notification low memory to user process. > > As you only wake one process how would you use this API from processes > which want to monitor and can free memory under load. Also what fairness > guarantees are there... Sorry, I

Re: [RFC][PATCH 5/5] /proc/zoneinfo enhancement

2008-01-15 Thread KOSAKI Motohiro
Hi alan > > show new member of zone struct by /proc/zoneinfo. > > > > Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> > > Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]> > > Minor NAK - Please put new fields at the end - it makes it less likely to

Re: rlim in proc//status

2008-01-15 Thread KOSAKI Motohiro
Hi sound good for me. a few question please. > + for (i=0; i + if (rlim_names[i]) > + buffer += sprintf(buffer, "Rlim%s:\t", rlim_names[i]); > + else > + buffer += sprintf(buffer, "Rlim%d:\t", i); this else is really necessary?

Re: [RFC] mmaped copy too slow?

2008-01-15 Thread KOSAKI Motohiro
Hi Peter, > > > While being able to deal with used-once mappings in page reclaim > > > could be a good idea, this would require us to be able to determine > > > the difference between a page that was accessed once since it was > > > faulted in and a page that got accessed several times. > > > >

Re: [RFC] mmaped copy too slow?

2008-01-15 Thread KOSAKI Motohiro
Hi Peter, While being able to deal with used-once mappings in page reclaim could be a good idea, this would require us to be able to determine the difference between a page that was accessed once since it was faulted in and a page that got accessed several times. it makes sense

Re: rlim in proc/pid/status

2008-01-15 Thread KOSAKI Motohiro
Hi sound good for me. a few question please. + for (i=0; iRLIM_NLIMITS; i++) { + if (rlim_names[i]) + buffer += sprintf(buffer, Rlim%s:\t, rlim_names[i]); + else + buffer += sprintf(buffer, Rlim%d:\t, i); this else is

Re: [RFC][PATCH 5/5] /proc/zoneinfo enhancement

2008-01-15 Thread KOSAKI Motohiro
Hi alan show new member of zone struct by /proc/zoneinfo. Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED] Signed-off-by: KOSAKI Motohiro [EMAIL PROTECTED] Minor NAK - Please put new fields at the end - it makes it less likely to break badly written tools. Oh I see. I applied your

Re: [RFC][PATCH 3/5] add /dev/mem_notify device

2008-01-15 Thread KOSAKI Motohiro
the core of this patch series. add /dev/mem_notify device for notification low memory to user process. As you only wake one process how would you use this API from processes which want to monitor and can free memory under load. Also what fairness guarantees are there... Sorry, I don't

Re: [RFC][PATCH 3/5] add /dev/mem_notify device

2008-01-15 Thread KOSAKI Motohiro
Hi Alan thank you for kindfull explain. the core of this patch series. add /dev/mem_notify device for notification low memory to user process. As you only wake one process how would you use this API from processes which want to monitor and can free memory under load. Also what

Re: [RFC][PATCH 4/5] memory_pressure_notify() caller

2008-01-15 Thread KOSAKI Motohiro
Hi Daniel The notification fires after only ~100 MB allocated, i.e., when page reclaim is beginning to nag from page cache. Isn't this a bit early? Repeating the test with swap enabled results in a notification after ~600 MB allocated, which is more reasonable and just before the

<    4   5   6   7   8   9   10   >