On Thu, 23 Aug 2007 17:47:44 +0800 yunfeng zhang wrote:
> Signed-off-by: Yunfeng Zhang <[EMAIL PROTECTED]>
>
> The mayor change is
> 1) Using nail arithmetic to maximum SwapDevice performance.
> 2) Add PG_pps bit to sign every pps page.
> 3) Some discussion about NUMA.
> See vm_pps.txt
>
>
On Thu, 23 Aug 2007 17:47:44 +0800 yunfeng zhang wrote:
Signed-off-by: Yunfeng Zhang [EMAIL PROTECTED]
The mayor change is
1) Using nail arithmetic to maximum SwapDevice performance.
2) Add PG_pps bit to sign every pps page.
3) Some discussion about NUMA.
See vm_pps.txt
Index:
To a two-CPU architecture, its page distribution just like theoretically
ABABAB
So every readahead of A process will create 4 unused readahead pages unless you
are sure B will resume soon.
Have you ever compared the results among UP, 2 or 4-CPU?
-
To unsubscribe from this list: send the
To a two-CPU architecture, its page distribution just like theoretically
ABABAB
So every readahead of A process will create 4 unused readahead pages unless you
are sure B will resume soon.
Have you ever compared the results among UP, 2 or 4-CPU?
-
To unsubscribe from this list: send the
yunfeng zhang wrote:
Performance improvement should occur when private pages of multiple
processes are messed up,
Ummm, yes. Linux used to do this, but doing virtual scans
just does not scale when a system has a really large amount
of memory, a large number of processes and multiple zones.
Performance improvement should occur when private pages of multiple processes
are messed up, such as SMP. To UP, my previous mail is done by timer, which only
shows a fact, if pages are messed up fully, current readahead will degrade
remarkably, and unused readaheading pages make a burden to
Performance improvement should occur when private pages of multiple processes
are messed up, such as SMP. To UP, my previous mail is done by timer, which only
shows a fact, if pages are messed up fully, current readahead will degrade
remarkably, and unused readaheading pages make a burden to
yunfeng zhang wrote:
Performance improvement should occur when private pages of multiple
processes are messed up,
Ummm, yes. Linux used to do this, but doing virtual scans
just does not scale when a system has a really large amount
of memory, a large number of processes and multiple zones.
yunfeng zhang wrote:
Any comments or suggestions are always welcomed.
Same question as always: what problem are you trying to solve?
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other
Any comments or suggestions are always welcomed.
-
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 http://www.tux.org/lkml/
Any comments or suggestions are always welcomed.
-
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 http://www.tux.org/lkml/
yunfeng zhang wrote:
Any comments or suggestions are always welcomed.
Same question as always: what problem are you trying to solve?
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other
Following arithmetic is based on SwapSpace bitmap management which is discussed
in the postscript section of my patch. Two purposes are implemented, one is
allocating a group of fake continual swap entries, another is re-allocating
swap entries in stage 3 for such as series length is too short.
Following arithmetic is based on SwapSpace bitmap management which is discussed
in the postscript section of my patch. Two purposes are implemented, one is
allocating a group of fake continual swap entries, another is re-allocating
swap entries in stage 3 for such as series length is too short.
You can apply my previous patch on 2.6.20 by changing
-#define VM_PURE_PRIVATE0x0400 /* Is the vma is only belonging
to a mm,
to
+#define VM_PURE_PRIVATE0x0800 /* Is the vma is only belonging
to a mm,
New revision is based on 2.6.20 with my previous patch,
You can apply my previous patch on 2.6.20 by changing
-#define VM_PURE_PRIVATE0x0400 /* Is the vma is only belonging
to a mm,
to
+#define VM_PURE_PRIVATE0x0800 /* Is the vma is only belonging
to a mm,
New revision is based on 2.6.20 with my previous patch,
You have an interesting idea of "simplifies", given
16 files changed, 997 insertions(+), 25 deletions(-)
(omitting your Documentation), and over 7k more code.
You'll have to be much more persuasive (with good performance
results) to get us to welcome your added layer of complexity.
If the
You have an interesting idea of simplifies, given
16 files changed, 997 insertions(+), 25 deletions(-)
(omitting your Documentation), and over 7k more code.
You'll have to be much more persuasive (with good performance
results) to get us to welcome your added layer of complexity.
If the whole
Current test based on the fact below in my previous mail
Current Linux page allocation fairly provides pages for every process, since
swap daemon only is started when memory is low, so when it starts to scan
active_list, the private pages of processes are messed up with each other,
Current test based on the fact below in my previous mail
Current Linux page allocation fairly provides pages for every process, since
swap daemon only is started when memory is low, so when it starts to scan
active_list, the private pages of processes are messed up with each other,
On Tue, 23 Jan 2007, yunfeng zhang wrote:
> re-code my patch, tab = 8. Sorry!
Please stop resending this patch until you can attend to the advice
you've been given: Pavel made several very useful remarks on Monday:
> No, this is not the way to submit major rewrite of swap subsystem.
>
> You
On Tue, 23 Jan 2007, yunfeng zhang wrote:
re-code my patch, tab = 8. Sorry!
Please stop resending this patch until you can attend to the advice
you've been given: Pavel made several very useful remarks on Monday:
No, this is not the way to submit major rewrite of swap subsystem.
You need to
re-code my patch, tab = 8. Sorry!
Signed-off-by: Yunfeng Zhang <[EMAIL PROTECTED]>
Index: linux-2.6.19/Documentation/vm_pps.txt
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.19/Documentation/vm_pps.txt
Patched against 2.6.19 leads to:
mm/vmscan.c: In function `shrink_pvma_scan_ptes':
mm/vmscan.c:1340: too many arguments to function `page_remove_rmap'
So changed
page_remove_rmap(series.pages[i], vma);
to
page_remove_rmap(series.pages[i]);
I've worked on 2.6.19, but when update to
yunfeng zhang wrote:
> My patch is based on my new idea to Linux swap subsystem, you can find
> more in Documentation/vm_pps.txt which isn't only patch illustration but
> also file changelog. In brief, SwapDaemon should scan and reclaim pages on
> UserSpace::vmalist other than current
Hi1
> My patch is based on my new idea to Linux swap subsystem, you can find more
> in
> Documentation/vm_pps.txt which isn't only patch illustration but also file
> changelog. In brief, SwapDaemon should scan and reclaim pages on
> UserSpace::vmalist other than current zone::active/inactive.
Hi1
My patch is based on my new idea to Linux swap subsystem, you can find more
in
Documentation/vm_pps.txt which isn't only patch illustration but also file
changelog. In brief, SwapDaemon should scan and reclaim pages on
UserSpace::vmalist other than current zone::active/inactive. The
yunfeng zhang wrote:
My patch is based on my new idea to Linux swap subsystem, you can find
more in Documentation/vm_pps.txt which isn't only patch illustration but
also file changelog. In brief, SwapDaemon should scan and reclaim pages on
UserSpace::vmalist other than current
Patched against 2.6.19 leads to:
mm/vmscan.c: In function `shrink_pvma_scan_ptes':
mm/vmscan.c:1340: too many arguments to function `page_remove_rmap'
So changed
page_remove_rmap(series.pages[i], vma);
to
page_remove_rmap(series.pages[i]);
I've worked on 2.6.19, but when update to
re-code my patch, tab = 8. Sorry!
Signed-off-by: Yunfeng Zhang [EMAIL PROTECTED]
Index: linux-2.6.19/Documentation/vm_pps.txt
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.19/Documentation/vm_pps.txt
My patch is based on my new idea to Linux swap subsystem, you can find more in
Documentation/vm_pps.txt which isn't only patch illustration but also file
changelog. In brief, SwapDaemon should scan and reclaim pages on
UserSpace::vmalist other than current zone::active/inactive. The change will
My patch is based on my new idea to Linux swap subsystem, you can find more in
Documentation/vm_pps.txt which isn't only patch illustration but also file
changelog. In brief, SwapDaemon should scan and reclaim pages on
UserSpace::vmalist other than current zone::active/inactive. The change will
32 matches
Mail list logo
