Re: 64GB NUMA-Q after pgcl

[Andrea Arcangeli <andrea@suse.de>]

On Sun, Mar 30, 2003 at 08:27:29PM -0800, William Lee Irwin III wrote:
> On Mon, Mar 31, 2003 at 01:19:45AM +0200, Andrea Arcangeli wrote:
> > Didn't you break the linux x86 ABI in mmap? the file offset must be a
> > multiple of the softpagesize and binary apps can break with -EINVAL with
> > pgcl. The workaround is to allocate it in anon mem but it's not coherent
> > if somebody does a change to the binary with MAP_SHARED, so still broken
> > semantics. In theory we could also have aliasing in the cache, but it
> > doesn't seem a good idea.
> 
> No, that's why it's nontrivial. Otherwise it'd be something like

I didn't expect that, I'm quite impressed now, I will check your
explanation thanks.

> On Mon, Mar 31, 2003 at 01:19:45AM +0200, Andrea Arcangeli wrote:
> > Since you have access to such a machine, can you please try to boot
> > 2.4.21pre5aa2 on such a machine? That must boot just fine too according

could you try 2.4.21pre5aa2 too if you have some time, I'd love to have
a confirm that it boots strightforward on such a machine (sure the
normal zone will be pretty small, not enough for AIM7 probably but still
ok for doing a large shmfs allocation and have smp_num_cpus tasks
attaching in large chunks to work on it) I really expect it to boot, if
not it must be a silly bug and I'll fix it, because it should definitely
boot on such x86 64G hardware (despite the normal zone will be so
small).

About you not caring anymore about the mem_map array size, that still
matters on the embedded usage, infact rmap on the embedded usage is the
biggest waste there, normally they don't even have swap so if something
you should use the rmap provided for truncate, rather than wasting
memory in the mem_map array.

Andrea