ost parser by Christoph Lameter [EMAIL PROTECTED], January 10, 2001
+
+ The proc file in /proc/sys/net/khttpd/document can either be set to a single
+webroot or
+ can contain a specification of a pathlist of webroots. Each path is prefixed by the
+virtual
+ hostnames in parentheses. For example.
+
diff -urN linux-orig/net/khttpd/rfc.c linux/net/khttpd/rfc.c
--- linux-orig/net/khttpd/rfc.c Mon Aug 23 10:41:25 1999
+++ linux/net/khttpd/rfc.c Fri Jan 12 21:23:26 2001
@@ -23,6 +23,34 @@
*
/
+/*
+ Virtual Host parser
On Fri, 12 Jan 2001, dean gaudet wrote:
anyhow a real network benchmark might show that kHTTPd latency is actually
not as broken as this one indicates. i'd however really hesitate to call
this a win.
Well as Arjan says: khttpd starves userspace and that might cause the
latency. I dont have
x(struct socket *sock);
diff -urN linux-orig/net/khttpd/rfc.c linux/net/khttpd/rfc.c
--- linux-orig/net/khttpd/rfc.c Mon Aug 23 10:41:25 1999
+++ linux/net/khttpd/rfc.c Sat Jan 13 18:45:28 2001
@@ -23,6 +23,34 @@
*
/
+/*
+
ck);
diff -urN linux/net/khttpd/rfc.c linux.new/net/khttpd/rfc.c
--- linux/net/khttpd/rfc.c Mon Aug 23 10:41:25 1999
+++ linux.new/net/khttpd/rfc.c Tue Jan 23 13:33:43 2001
@@ -23,6 +23,34 @@
*
/
+/*
+ Virtual
These tests were done with 2 Celeron-433 processors across a 100 mbit
link.
The server was running 2.4.1-pre8 + my patches and boa / apache / khttpd.
The server was running other services while doing the test.
The client was running 2.2.17.
Boa is still very close to khttpd. Apache falls way
Following is a series of oopses that kept my server not responding for a
while this morning. Running lots of services amoung them a hub for the
openproject IRC network:
May 30 07:58:01 melchi kernel: invalid operand:
May 30 07:58:01 melchi kernel: CPU:0
May 30 07:58:01 melchi kernel:
With both version I get the "booting linux" message and then the first
line of the kernel messages. Then its dead. Have tried to change the kernel
configuration but to no avail.
2.4.0test2 works fine.
How can I figure out what is wrong?
-
To unsubscribe from this list: send the line
On 18 Sep 2000, Juan J. Quintela wrote:
"christoph" == Christoph Lameter [EMAIL PROTECTED] writes:
christoph With both version I get the "booting linux" message and then the first
christoph line of the kernel messages. Then its dead. Have tried to change th
On Sun, Sep 17, 2000 at 06:14:11PM -0700, Christoph Lameter wrote:
With both version I get the "booting linux" message and then the first
line of the kernel messages. Then its dead. Have tried to change the kernel
configuration but to no avail.
The problem was that the cputy
Tried burning a cd with pre4 and devfs. There is no /dev/sg0 and /dev/scsi
is empty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Is there something wrong with the tcp stack?
bash-2.04$ ping linuxtoday.com
PING linuxtoday.com (63.236.72.248) from 216.59.82.89 : 56 data bytes
64 bytes from 63.236.72.248: icmp_seq=0 ttl=244 time=103.7 ms
64 bytes from 63.236.72.248: icmp_seq=1 ttl=244 time=104.3 ms
--- linuxtoday.com ping
On Tue, 3 Oct 2000, Rik van Riel wrote:
On Tue, 3 Oct 2000, Christoph Lameter wrote:
I frequently experience lockups since test9-pre7. It usually
happens when leaving pine. Pine asks if the deleted messages
should be purged. Say yes and everything freezes up.
# CONFIG_MAGIC_SYSRQ
Comparing CD contents with the original after burning showed mismatches 4
times in a row. Booted into linux 2.2.18 and everything is fine.
Together with the events of freezing in pine I would suggest that there is
something in the kernel scribbling memory.
I am back to 2.2 for good for now.
I got a directory /a/yy that I tried to erase with rm -rf /a/yy.
rm hangs...
ls gives the following output:
ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
ls:
On Mon, 26 Mar 2001, Chris Mason wrote:
On Saturday, March 24, 2001 11:56:08 AM -0800 Christoph Lameter
[EMAIL PROTECTED] wrote:
I got a directory /a/yy that I tried to erase with rm -rf /a/yy.
rm hangs...
ls gives the following output:
ls: /a/yy/cache3A0F94EA0A00557.html
On Mon, 26 Mar 2001, Chris Mason wrote:
On Monday, March 26, 2001 03:21:29 PM -0800 Christoph Lameter
On Mon, 26 Mar 2001, Chris Mason wrote:
On Saturday, March 24, 2001 11:56:08 AM -0800 Christoph Lameter
[EMAIL PROTECTED] wrote:
I got a directory /a/yy that I tried to erase with rm
On Tue, 27 Mar 2001, Chris Mason wrote:
On Monday, March 26, 2001 06:57:37 PM -0800 Christoph Lameter
[EMAIL PROTECTED] wrote:
On Mon, 26 Mar 2001, Chris Mason wrote:
On Monday, March 26, 2001 03:21:29 PM -0800 Christoph Lameter
On Mon, 26 Mar 2001, Chris Mason wrote:
On Saturday
On Tue, 27 Mar 2001, Chris Mason wrote:
On Tuesday, March 27, 2001 08:21:07 AM -0800 Christoph Lameter
[EMAIL PROTECTED] wrote:
-debugreiserfs, 2000-
reiserfsprogs 3.x.0h
9454 is free in true bitmap
On Tue, 27 Mar 2001, Chris Mason wrote:
Just to make sure I understand, you had the exact same errors before
running fsck? Same files could not be deleted?
Correct.
I think this is a problem with the reiserfs code in the kernel. I never
ran reiserfsck before this problem surfaced. The
On Tue, 27 Mar 2001, Chris Mason wrote:
On Tuesday, March 27, 2001 11:14:57 AM -0800 Christoph Lameter
[EMAIL PROTECTED] wrote:
I should have been more clear. Everyt ime you mount the filesystem, a it
prints the hash used. This is probably recorded in your log files, either
'Using r5 hash
had. If
its specified then SLAB_HWCACHE_ALIGN is also specified.
The flag is confusing, inconsistent and has no purpose.
Remove it.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Index: linux-2.6.21-rc6/include/linux/slab.h
On Tue, 17 Apr 2007, Larry Woodman wrote:
out_of_memory() does not panic when sysctl_panic_on_oom is set
if constrained_alloc() does not return CONSTRAINT_NONE. Instead,
out_of_memory() kills the current process whenever constrained_alloc()
returns either CONSTRAINT_MEMORY_POLICY or
On Tue, 17 Apr 2007, Siddha, Suresh B wrote:
While going through the slab code, I observed that alien caches are
not getting resized, when user changes the slab tunables. Appended patch
tries to fix this. Please review and let me know if I missed anything.
Let it be. We have not resized the
On Tue, 17 Apr 2007, Larry Woodman wrote:
On Tue, 2007-04-17 at 14:39 -0700, Christoph Lameter wrote:
It recreates the old problem that we OOM while we still have memory
in other parts of the system.
How, by the time we get here we have already decided we are going to
OOMkill
On Wed, 18 Apr 2007, Yasunori Goto wrote:
If panic_on_oom is 1, only panic if mempolicy/cpuset is not used.
And if panic_on_oom is 2, panic on all case.
This might be desirable.
Sounds good. Add some documentation mentioned that this may panic your
system if there is still plenty of memory
Dickins [EMAIL PROTECTED]
Acked-by: Christoph Lameter [EMAIL PROTECTED]
-
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
On Wed, 18 Apr 2007, Ethan Solomita wrote:
Any new ETA? I'm trying to decide whether to go back to your original
patches or wait for the new set. Adding new knobs isn't as important to me as
having something that fixes the core problem, so hopefully this isn't waiting
on them. They could
On Thu, 19 Apr 2007, Ethan Solomita wrote:
H Sorry. I got distracted and I have sent them to Kame-san who was
interested in working on them.
I have placed the most recent version at
http://ftp.kernel.org/pub/linux/kernel/people/christoph/cpuset_dirty
Do you expect any
Variable Order Page Cache Patchset
This patchset modifies the core VM so that higher order page cache pages
become possible. The higher order page cache pages are compound pages
and can be handled in the same way as regular pages.
The order of the pages is determined by the order set up in the
in the address space structure means that the order of the
pages in the page cache can be varied per file that a filesystem creates.
This means we can keep small 4k pages for small files. Larger files can
be configured by the file system to use a higher order.
Signed-off-by: Christoph Lameter [EMAIL
to support faulting
higher order pages but for now we are content with buffered I/O on higher
order pages.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
fs/ramfs/file-mmu.c | 11 +++
fs/ramfs/inode.c | 15 ---
include/linux/ramfs.h |1 +
3 files changed
-by: Christoph Lameter [EMAIL PROTECTED]
---
mm/filemap.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc7/mm/filemap.c
===
--- linux-2.6.21-rc7.orig/mm/filemap.c 2007-04-19 09:11:13.0
there are no changes needed to release higher order page
cache pages.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
include/linux/pagemap.h | 15 +--
mm/filemap.c|9 +
2 files changed, 14 insertions(+), 10 deletions(-)
Index: linux-2.6.21-rc7/include
---
include/linux/pagemap.h | 27 +++
1 file changed, 27 insertions(+)
Index: linux-2.6.21-rc7/include/linux/pagemap.h
===
--- linux-2.6.21-rc7.orig/include/linux/pagemap.h 2007-04-18
Variable Order Page Cache: Fixup fallback functions
Fixup the fallback function in fs/libfs.c to be able to handle
higher order page cache pages.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
fs/libfs.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
Index
Variable Order Page Cache: Fix up mm/filemap.c
Fix up the function in mm/filemap.c to use the variable page cache.
This is pretty straightforward:
1. Convert the constants to function calls.
2. Use the mapping flush function
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
mm/filemap.c
Debugging patch
Show some output as to what is going on.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
fs/ramfs/inode.c |1 +
mm/filemap.c |8
2 files changed, 9 insertions(+)
Index: linux-2.6.21-rc7/fs/ramfs/inode.c
On Thu, 19 Apr 2007, Nish Aravamudan wrote:
NR_FILE_PAGES,
+ 1 mappig-order);
Typo? should be mapping-order?
Correct. Sigh. Why do these things creep in at the last minute before
posting???
-
To unsubscribe from this list: send the line unsubscribe
On Thu, 19 Apr 2007, Adam Litke wrote:
On 4/19/07, Christoph Lameter [EMAIL PROTECTED] wrote:
@@ -331,11 +331,15 @@ int simple_prepare_write(struct file *fi
unsigned from, unsigned to)
{
if (!PageUptodate(page)) {
- if (to - from
On Thu, 19 Apr 2007, Badari Pulavarty wrote:
On Thu, 2007-04-19 at 09:35 -0700, Christoph Lameter wrote:
Variable Order Page Cache Patchset
..
mm/built-in.o: In function `__generic_file_aio_write_nolock':
filemap.c:(.text+0x295c): undefined reference to `page_cache_shift'
filemap.c
On Thu, 19 Apr 2007, Andi Kleen wrote:
We likely need actual defragmentation support.
To be honest it looks quite pointless before this is solved. So far it is
not even clear if it is feasible to solve it.
We have done order 1 / 2 allocations for some limited purposes for some
time (task
On Fri, 20 Apr 2007, David Chinner wrote:
So looking at this the main thing for converting a filesystem is some extra
bits in the mount process and replacing PAGE_CACHE_* macros with
page_cache_*() wrapper functions.
Right.
We can probably set all this up trivially with XFS by allowing
On Fri, 20 Apr 2007, David Chinner wrote:
I think PAGE_CACHE_SIZE is a redundant define with these
modifications. The page cache size in now variable and it is based
on a multiple of PAGE_SIZE. Hence I suggest that PAGE_CACHE_SIZE and
it's derivitives should be made to go away completely
On Fri, 20 Apr 2007, Maxim Levitsky wrote:
First of all, today, packet writing on cd/dvd doesn't work well, it is very
slow because
now all file-systems are limited to 4k-barrier and cd/dvd can write only
32k/64k packets.
This is why a pktcdvd was written and it emulates those 4k sectors
On Fri, 20 Apr 2007, Neil Brown wrote:
Not sure how best to fix this one kmem_cache_destroy currently
doesn't know which alias is being destroyed.
The aliases are there for decorative purposes when running without
debugging. If one switches on debugging then it matters but then the
On Thu, 19 Apr 2007, William Lee Irwin III wrote:
Oh dear. Per-file pagesizes are foul. Better to fix up the pagecache's
radix tree than to restrict it like this. There are other attacks on the
multiple horizontal internal tree node allocation problem beyond
outright B+ trees that allow radix
On Fri, 20 Apr 2007, Neil Brown wrote:
On Thursday April 19, [EMAIL PROTECTED] wrote:
On Fri, 20 Apr 2007, Neil Brown wrote:
Not sure how best to fix this one kmem_cache_destroy currently
doesn't know which alias is being destroyed.
The aliases are there for decorative
Another approach drop the symlinks completely. Just
write a message to the syslog informing the user that we
created an alias. If debugging is off then the user would have to consult
the syslog to find aliases.
Index: linux-2.6.21-rc6/mm/slub.c
On Fri, 20 Apr 2007, Jens Axboe wrote:
This works fine as long as you are in the submitter context, but once
you pass the into the block layer, we don't have any way to find the
address space (at least we don't want to). Would something like this be
workable, name withstanding:
static
On Fri, 20 Apr 2007, Mel Gorman wrote:
While this looks fine, it seems that clear_huge_page() and
clear_mapping_page() could share a common helper. I also note that
clear_huge_page() calls cond_reched() and this doesn't which may be the
type of different behavior we want to avoid.
I am
On Fri, 20 Apr 2007, Benjamin LaHaise wrote:
On Fri, Apr 20, 2007 at 08:43:56PM +0900, Yasunori Goto wrote:
The current panic_on_oom may not work if there is a process using
cpusets/mempolicy, because other nodes' memory may still free.
But some people want failover by panic ASAP even
On Fri, 20 Apr 2007, Mel Gorman wrote:
So the difference here appears to be that specifying an order means you
can't mmap(). right?
That's fair enough for the moment but relaxing would make ramfs
potentially usable as a replacement for hugetlbfs so there would be just
one ram-based
On Fri, 20 Apr 2007, Mel Gorman wrote:
I believe there is an assumption in parts of reclaim that LRU pages are
order-0. An interesting bug or two is likely to rear its head there.
Correct. We need to deal with reclaim etc.
Note that this is proof-of-concept. Lots of functionality is missing
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
On Fri, Apr 20, 2007 at 02:42:27PM +0100, Mel Gorman wrote:
That's fair enough for the moment but relaxing would make ramfs
potentially usable as a replacement for hugetlbfs so there would be just
one ram-based filesystem instead of two.
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
On Fri, Apr 20, 2007 at 09:30:30AM -0700, Christoph Lameter wrote:
We can map arbitrary 4k chunks of larger pages.
The core VM can do that but the hugetlb architectural code can't fall
back to smaller page sizes. It also should not be put
it must honor.
On Fri, Apr 20, 2007 at 10:15:00AM -0700, Christoph Lameter wrote:
Wel we could potentially add a handle_pmd_fault to the vm...?
Unconscionably foul. I guess x86-uber-alles pagetables in the core vm
is the Linux way, though.
Yes sadly true. The alternative is to add a page table
Variable Order Page Cache: Readahead fixups
Readahead is now dependent on the page size. For larger page sizes
we want less readahead.
Add a parameter to max_sane_readahead specifying the page order
and update the code in mm/readahead.c to be aware of variant
page sizes.
[WARNING untested
Variable Order Page Cache: mmap_nopage and mmap_populate
Fix up both functions to be able to operate on arbitrary order
pages. However, both functions establish page table entries
in PAGE_SIZE only and the offset and pgoffset when calling
both functions is always in PAGE_SIZE units. Thus the
Some ideas for memory.c pieces. Just junk like the earlier patches.
---
mm/memory.c | 108
1 file changed, 66 insertions(+), 42 deletions(-)
Index: linux-2.6.21-rc7/mm/memory.c
On Fri, 20 Apr 2007, Dave Kleikamp wrote:
On Fri, 2007-04-20 at 12:05 +0100, Mel Gorman wrote:
comments about missing page_cache_size() covered elsewhere. However, I
note that Dave Kleikamp might be interested in this changing of
page_cache_size() from the perspective of page cache
On Wed, 18 Apr 2007, William Lee Irwin III wrote:
Mark the runqueues cacheline_aligned_in_smp to avoid false sharing.
False sharing for a per cpu data structure? Are we updating that
structure from other processors?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
On Wed, 18 Apr 2007, William Lee Irwin III wrote:
Mark the runqueues cacheline_aligned_in_smp to avoid false sharing.
On Fri, Apr 20, 2007 at 12:24:17PM -0700, Christoph Lameter wrote:
False sharing for a per cpu data structure
On Fri, 20 Apr 2007, William Lee Irwin III wrote:
I'm not really convinced it's all that worthwhile of an optimization,
essentially for the same reasons as you, but presumably there's a
benchmark result somewhere that says it matters. I've just not seen it.
If it is true that we frequently
not support. Remove the check
for unimplemented flags from SLUB.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Index: linux-2.6.21-rc6/include/linux/slab.h
===
--- linux-2.6.21-rc6.orig/include/linux/slab.h 2007-04-20 18:07
On Fri, 20 Apr 2007, Ethan Solomita wrote:
cpuset_write_dirty_map.htm
In __set_page_dirty_nobuffers() you always call cpuset_update_dirty_nodes()
but in __set_page_dirty_buffers() you call it only if page-mapping is still
set after locking. Is there a reason for the difference? Also a
{
int a,b,c;
struct list_head;
} __cacheline_aligned_in_smp;
test_slab_cache = KMEM_CACHE(test_slab, SLAB_PANIC)
willl create a new slab named test_slab of the size
sizeof(struct test_slab) and aligned to the alignment of test
slab. If it fails then we panic.
Signed-off-by: Christoph
How do I remove all references to an object in sysfs? The following patch
attempt to get that functionality in sysfs but I am not that familiar with
it. Help
SLUB: Remove alias before installing symlink
We cannot really track the aliases that are created when aliasing
a slab.
On Sat, 21 Apr 2007, Ethan Solomita wrote:
Exactly -- your patch should be consistent and do it the same way as
whatever your patch is built against. Your patch is built against a kernel
that subtracts off highmem. Do it... are you handing off the patch and are
done with it?
Yes as said
On Sun, 22 Apr 2007, Andrew Morton wrote:
This patch causes a use-uninitialised crash in the locks code.
Sigh. The only case in which the check is inverted in a constructor.
Invert the check.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Index: linux-2.6.21-rc6/fs/locks.c
On Mon, 23 Apr 2007, Neil Brown wrote:
Another option might be to name each cache actually created with a
unique name, and then create a symlink for each cache that was asked
for (whether it was created or whether a pre-existing cache was used).
Then being lazy about deletion shouldn't be a
On Sat, 21 Apr 2007, Peter Zijlstra wrote:
This is enormously wrong for CONFIG_NR_CPUS=1024 on a 2-way.
Right, I knew about that but, uhm.
I wanted to make that num_online_cpus(), and install a hotplug notifier
to fold the percpu delta back into the total on cpu offline.
Use nr_cpu_ids
On Mon, 23 Apr 2007, Peter Zijlstra wrote:
Ooh, thats handy... /me ditches the hotplug code again.
That is, unless its very common to have half empty boxens.. ?
Its up to the arch code to establish reasonable boundaries.
-
To unsubscribe from this list: send the line unsubscribe
will then no longer generate symlinks and
special unique names.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Index: linux-2.6.21-rc6/mm/slub.c
===
--- linux-2.6.21-rc6.orig/mm/slub.c 2007-04-23 13:08:41.0 -0700
+++ linux
that there is no function to allocate a page for the page cache
with a gfp mask. So we create one ORing the context gfp flags with the gfp flags
from the mapping.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
include/linux/pagemap.h | 10 --
mm/filemap.c|3
On Mon, 23 Apr 2007, Andrew Morton wrote:
+static inline struct page *page_cache_alloc_mask(struct address_space *x,
+ gfp_t gfp)
+{
+ return __page_cache_alloc(mapping_gfp_mask(x) | gfp);
+}
Usually we use the term mask to imply an AND function, not an OR
to be consulted in order to get DMA
and HIGHMEM allocations etc right.
So fix grow_dev_page to do the same as __page_symlink calls. Retrieve the
mask from the mapping and then remove __GFP_FS.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
fs/buffer.c |3 ++-
1 file changed, 2
to
find_or_create_page needs to be handled.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
mm/filemap.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc7/mm/filemap.c
===
--- linux-2.6.21
There are a series of open coded reimplementation of memclear_highpage_flush
all over the page cache code. Call memclear_highpage_flush in those locations.
Consolidates code and eases maintenance.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
fs/buffer.c | 77
On Tue, 24 Apr 2007, Neil Brown wrote:
On Monday April 23, [EMAIL PROTECTED] wrote:
Would this work? Contains a solution somewhat along the lines of your
thoughts on the subject.
Concept seems sound.
Code needs a kfree of the name returned by create_unique_id, and I
think
that). We will detect the duplications as
as soon as debugging is enabled because we will then no longer
generate symlinks and special unique names.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Index: linux-2.6.21-rc6/mm/slub.c
On Tue, 24 Apr 2007, Satyam Sharma wrote:
On 4/24/07, Christoph Lameter [EMAIL PROTECTED] wrote:
There are a series of open coded reimplementation of memclear_highpage_flush
all over the page cache code. Call memclear_highpage_flush in those
locations.
Consolidates code and eases
On Mon, 23 Apr 2007, David Rientjes wrote:
oom_kill_task() calls __oom_kill_task() to OOM kill a selected task.
When finding other threads that share an mm with that task, we need to
kill those individual threads and not the same one.
Obvious fix. It was broken by
On Tue, 24 Apr 2007, Hugh Dickins wrote:
I've not yet looked at the patch under discussion, but this remark
prompts me... a couple of days ago I got very worried by the various
hard-wired GFP_HIGHUSER allocations in mm/migrate.c and mm/mempolicy.c,
and wondered how those would work out if
On Fri, 20 Apr 2007, Siddha, Suresh B wrote:
Last I checked it was workload-dependent, but there were things that
hammer it. I mostly know of the remote wakeup issue, but there could
be other things besides wakeups that do it, too.
remote wakeup was the main issue and the 0.5%
On Tue, 24 Apr 2007, Hugh Dickins wrote:
I've not yet looked at the patch under discussion, but this remark
prompts me... a couple of days ago I got very worried by the various
hard-wired GFP_HIGHUSER allocations in mm/migrate.c and mm/mempolicy.c,
and wondered how those would work out if
On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
.5% is usually in the noise ratio. Are you consistently seeing an
improvement or is that sporadic?
No. This is consistent. I am waiting for the perf data on a much much bigger
NUMA box.
Anyhow, this is a straight forward optimization and
On Tue, 24 Apr 2007, Hugh Dickins wrote:
And if a page is in the wrong area then it can be bounced before I/O
is performed on it.
I think that much is also true, but not where the problem lies.
Isn't the problem that filesystems using these block devices
expect their metadata to be
On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
On Tue, Apr 24, 2007 at 10:47:45AM -0700, Christoph Lameter wrote:
On Tue, 24 Apr 2007, Siddha, Suresh B wrote:
Anyhow, this is a straight forward optimization and needs to be done. Do
you
have any specific concerns?
Yes there should
On Tue, 24 Apr 2007, Andrew Morton wrote:
I think that much is also true, but not where the problem lies.
Isn't the problem that filesystems using these block devices
expect their metadata to be accessible without kmap calls?
yup. wherever we dereference buffer_head.b_data we're
On Tue, 24 Apr 2007, Hugh Dickins wrote:
I was certainly ignorant of that; but I'm not convinced it eliminates
the potential issue. For a start, sys_move_pages seems not to involve
mempolicies at all - I don't see what prevents it migrating blockdev
pages away from the only node which has
On Tue, 24 Apr 2007, Hugh Dickins wrote:
Or Christoph may prevail in persuading there's no such problem.
This is pointless. NUMA allocations can only be controlled for the highest
zone. If we switch to a lower zone then we allocate on a different zone
than the user requested.
-
To
On Tue, 24 Apr 2007, Andrew Morton wrote:
No, think of the following scenario:
- file I/O causes a read of an ext2 file's bitmap. The bitmap is
brought into /dev/hda1's pagecache using !__GFP_HIGHMEM
- references are released against that page and it's now just clean
reclaimable
On Tue, 24 Apr 2007, Andrew Morton wrote:
A highmem page can have buffers???
yep. Take a 4k page which is stored in four discontiguous 1k disk blocks. The
data at page_buffers(page) is the sole way in which we track which parts of
the page belong to which blocks of the disk.
But I see no
On Tue, 24 Apr 2007, Hugh Dickins wrote:
On Tue, 24 Apr 2007, Christoph Lameter wrote:
On Tue, 24 Apr 2007, Hugh Dickins wrote:
Or Christoph may prevail in persuading there's no such problem.
This is pointless. NUMA allocations can only be controlled for the highest
zone. If we
On Tue, 24 Apr 2007, Andrew Morton wrote:
I would say that the filesystem is broke if it has such expectations
regardless of page migration.
Others disagree ;)
The filesystem has *told* the core kernel what its allocation constraints
are by setting up mapping_gfp_mask(). If the core
On Tue, 24 Apr 2007, Andrew Morton wrote:
Then I think we should disable page migration for allocations that do not
allow access to the policy zone. That would fix it.
Can't we use mapping_gfp_mask() when allocating the destination page?
There is no point in migrating something if you
On Tue, 24 Apr 2007, Andrew Morton wrote:
Nothing special apart from
the usual problem with serial not accepting characters that we had for
awhile now.
I wasn't aware of that one.
I use a serial console on my x86_84 box. For a while now I can see all
output but I cannot type any
On Tue, 24 Apr 2007, Andrew Morton wrote:
mapping_gfp_mask if a pretty foul thing. Adding
struct page (*alloc_page)(struct address_space *mapping);
to address_space_operations would be a quite nice cleanup.
Ummm... If things would be that simple... I think we need
struct page
On Wed, 25 Apr 2007, Eric Dumazet wrote:
struct radix_tree_root page_tree; /* radix tree of all pages */
rwlock_ttree_lock; /* and rwlock protecting it */
+#ifdef CONFIG_LARGE_BLOCKSIZE
+ unsigned intorder; /* Page order of the
1 - 100 of 10010 matches
Mail list logo
