From: Martin J. B. <mb...@ar...> - 2002-10-15 01:32:04
|
>> No, the NUMA code in the kernel doesn't support that anyway. >> You have to use zholes_size, and waste some struct pages, >> or config_nonlinear. Either way you get 1 memblk. > > I thought zholes stuff freed the struct pages. Maybe that was done > by hand. The only place I see that used in generic code is calculate_zone_totalpages, free_area_init_core, free_area_init_node, none of which seem to do that. But cscope might be borked again, I guess. Must be done in each arch if at all ... which arch did you think did it? M. |
From: William L. I. I. <wl...@ho...> - 2002-10-15 01:44:10
|
At some point in the past, I wrote: >> I thought zholes stuff freed the struct pages. Maybe that was done >> by hand. On Mon, Oct 14, 2002 at 06:29:49PM -0700, Martin J. Bligh wrote: > The only place I see that used in generic code is > calculate_zone_totalpages, free_area_init_core, free_area_init_node, > none of which seem to do that. But cscope might be borked again, I > guess. Must be done in each arch if at all ... which arch did you > think did it? Not sure, ISTR something about this going on but I don't see any extant examples. At any rate, it should be easy to do it by hand, just make sure there are struct pages tracking the holes in mem_map and free the space in mem_map that would track the holes. Bill |
From: William L. I. I. <wl...@ho...> - 2002-10-15 02:01:14
|
On Mon, Oct 14, 2002 at 06:29:49PM -0700, Martin J. Bligh wrote: >> The only place I see that used in generic code is >> calculate_zone_totalpages, free_area_init_core, free_area_init_node, >> none of which seem to do that. But cscope might be borked again, I >> guess. Must be done in each arch if at all ... which arch did you >> think did it? On Mon, Oct 14, 2002 at 06:40:23PM -0700, William Lee Irwin III wrote: > Not sure, ISTR something about this going on but I don't see any extant > examples. At any rate, it should be easy to do it by hand, just make > sure there are struct pages tracking the holes in mem_map and free the > space in mem_map that would track the holes. And buddy bitmaps and ->node_valid_addr too. Which stands a good chance of explaining why it broke, if it ever worked. Bill |
From: <ebi...@xm...> - 2002-10-15 17:22:56
|
Matthew Dobson <col...@us...> writes: > Eric W. Biederman wrote: > > Matthew Dobson <col...@us...> writes: > >>Greetings & Salutations, > >> Here's a wonderful patch that I know you're all dying for... Memory > >>Binding! It works just like CPU Affinity (binding) except that it binds a > >>processes memory allocations (just buddy allocator for now) to specific memory > > >>blocks. > > Due we want this per numa area or simply per zone? My suspicion is that > > internally at least we want this per zone. > I think that per memory block is better. [snip] > I'm not fanatically > opposed to per zone binding, though, and if there is a general agreement that it > would be better that way, I don't think it would be unreasonably difficult to > change it. My only feeling with zones is that it could be useful in the non numa cases, if it was per zone. But unless this API becomes is a pure hint we need at least one specifier that says writing to swap is o.k. > > The API doesn't make much sense at the moment. > Hmm.. That is unfortunate, I'd aimed to make it as simple as possible. Simple is good only if the proper pieces are connected. > > 1) You are operating on tasks and not mm's, or preferably vmas. > Correct. There are plans (somewhere inside my cranium) to allow binding at that > > granularity. For now, per task seemed an appropriate level. It makes it terribly unpredictable. If you have two threads each bound to a different location there are race conditions which area the memory is allocated from. > > 2) sys_mem_setbinding does not move the mm to the new binding. > Also correct. A task may wish to allocate several large data structures from > one memory area, rebind, do more allocations, rebind, ad nauseum. There are > plans to have a flag that, if set, would force relocation of all currently > allocated memory. Actually the bindings need to stick to the vma or to the struct address_space. Otherwise you are talking about an allocation hint, as swapping can trivially undue it and nothing happens when the actual call is made. A hint is a very different thing from a binding. And if we stick this to struct address_space for the non anonymous cases having a fmem_setbinding(struct fd) that works on files would be a useful thing as well. > > 5) mprotect is the more natural model rather than set_cpu_affinity. > Well, I think that may be true for the API you are imagining (per zone, per > mm/vma, etc), not the one that I've written. For a binding with respect to memory I imagine things like mlock(). For anything else you are talking a future hint to the memory allocators, which feels less much useful. Eric |