Recent blog entries for wli

Page clustering is looking pretty stable except for the swap refcounting issue. I managed to blame the wild NMI issue on qlogicisp.c and I'm just sort of grinding away slowly at debugging the do_anonymous_page() antifragmentation heuristics.

cpumask_t stuff is going slow. Probably needs non-x86 support.

I'll get some more ideas eventually.

Got page clustering and NR_CPUS > BITS_PER_LONG stuff on the chopping block. No idea if/when stuff will get merged. Page clustering is taking longer than expected to get bugs flushed out of it. Still hammering it hard.

Wow, it's been a while. Well, I ended up doing a crippled "map shm with 2M/4M pages" flag instead of MPSS, lazy_buddy has pretty much been killed, shared pagetables ended up getting done by dmc, and gang allocation stuff by mbligh. Ugh =(

At least -for_each_task went somewhere. Now I'm pretty much doing hugetlbfs maintenance and doing seek & destroy on various kinds of braindamage.

Shared pagetables are festering. Instead I appear to be going after scsi_malloc() and trimming down the sizes of various data structures, and backporting things too. Oh well, one can only do so much. lazy_buddy and gang_cpu are sort of on hold, though progress seems to be happening.

Looks like I need to do things faster. All the stuff I've been talking about really needs to happen, which I've known all along but seems to be getting impressed upon me by observing various things. No sleep this weekend...

Pushed another lazy_buddy out the door and testers/reviewers are nowhere to be found. Maybe I should just keep moving until they do chime in. Shared pagetables, here I come...

Looks like openlogging.org fell off the net and I can't bk commit anything. Which is somewhat painful as I'd like to avoid batching unrelated things together in a given changeset.

The bugreporter seems to have indicated that the rmap13 bug was created by an independent patch used in combination with it. What a relief!

A number of strategies seem to have surfaced for dealing with kva exhaustion:

1. making kernel/user address spaces disjoint
   
2. dynamically mapping large data structures
   
3. reserving a region of per-process kva for windowing potentially large things predominantly accessed from the context of its creator
   
4. shrinking the size of various data structures
   
5. shrinking caches more aggressively
   
6. reserving a larger global windowing region
   
7. reserving per-cpu windowing regions with scheduler support
   
8. daemons parked in front of large structures stealing the user portion of the address space for windowing their oversized data structure
   
9. statically reserving per-process kva for dynamically mapping things like pagetables with strong process affinity
   
10. doing nothing whatsoever and using 64-bit hardware instead (supposedly the preferred course of action which is not really acceptable to those I'm helping)
    

Highmem is really evil.

Making fork() not copy pte's for file-backed vma's seems to have some very difficult to trace issues. As best as I can tell things somehow end up faulting in garbage.

Poking around fault paths and such has led me to consider beautifying it somewhat by fleshing out the segment driver -like approach and some pure non-semantic beautification of rbtree manipulation code. I might also try using a different kind of tree if I feel like going in for the long haul. Not that I haven't done that before.

pagemap_lru_lock things are going well. Just taking it slowly from here so bugs I may have missed don't show up in larger groups than can be effectively handled, and not feeding stuff to riel until after the issues from the last batch of things sent to him have been handled. There's an annoying one where the bugreporter has vaporized and I can't get anything close to useful info as to what happened that I'd like to get a grip on, but short of literally flying out to meet the guy, sitting on his doorstep until he reappears, and borrowing his box to debug on (which isn't going to happen) I'm not sure what can really be done.

It looks like rmap is getting close to (or at) parity on NUMA-Q now with a rollup of the pending changes so I'm slowing that down and keeping things stable. Now I'm helping to chase highmem stability issues and have some fork() efficiency issues on at a lower priority. Highmem is evil. Very evil. It's going to take a bunch of us grinding away at it full-time to make this stuff work. The niceness of direct-mapping the kernel virtual address space turns into a kva-exhaustion horror beyond imagination as dynamic:direct ratios go up. There will be much pain.

Trying to debug the races with the pagemap_lru_lock breakup all week. Mostly just singlestepping and trying to debug the simulator. Nothing to see here, move on.

So nothing really got done this weekend. It wouldn't have helped to run the benchmarks without having the analysis code I wanted to use the benchmarks as testcases for ready for the occasion. Reimplementing math libraries there aren't free equivalents of is a big PITA.

I got a real profile instead of a description and the signs point to too many calls to add_timer(), mod_timer(), and del_timer() as opposed to cache-blowing in cascade_timers(), which surprised me but relieves me of the burden of writing the umpteenth priority queue. It also appears to be specific to ip_conntrack which I'm not sure is one of my priorities.

Following the yellow brick profile...