Messages in this thread | | | Date | Mon, 31 Mar 2003 10:55:53 -0800 | From | William Lee Irwin III <> | Subject | Re: 64GB NUMA-Q after pgcl |
| |
On Sun, Mar 30, 2003 at 08:27:29PM -0800, William Lee Irwin III wrote: >> No, that's why it's nontrivial. Otherwise it'd be something like
On Mon, Mar 31, 2003 at 01:19:45AM +0200, Andrea Arcangeli wrote: > I didn't expect that, I'm quite impressed now, I will check your > explanation thanks.
On Mon, Mar 31, 2003 at 08:35:06PM +0200, Andrea Arcangeli wrote: > 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).
I'll see what those I have to answer to think. I'll have to warn you, the NUMA-Q code in 2.4.x hasn't been very heavily focused on recently so it may depend on someone testing/debugging the 2.4.x-based tree on another machine (we haven't quite lost all the NUMA-Q's in our lab to this) before the RAM goes away. I myself don't have guarantees I'll have sufficient time for "must do" things -- if I run out of time it's gone regardless. Extras are definitely a question of chance.
On Mon, Mar 31, 2003 at 08:35:06PM +0200, Andrea Arcangeli wrote: > 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.
They should be able to utilize the same technique for cutting down mem_map, and there are pending bits around that allow the pte_chain allocations to be eliminated entirely for file-backed memory, and so embedded systems's needs can be accommodated with a bit of extra adjustment for !CONFIG_SWAP and they'll never see pte_chains again.
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |