2.5.73-wli-1

* 2.5.73-wli-1
@ 2003-06-25  1:05 William Lee Irwin III
  2003-06-26  5:29 ` 2.5.73-wli-1 William Lee Irwin III
  0 siblings, 1 reply; 2+ messages in thread
From: William Lee Irwin III @ 2003-06-25  1:05 UTC (permalink / raw)
  To: linux-kernel

Available from:
ftp://ftp.kernel.org/pub/linux/kernel/people/wli/kernels/2.5.73/2.5.73-wli-1/2.5.73-wli-1.bz2

Gee, I've not quite been fast enough to get more than one out per point
release. No matter. The content is good enough (or bad enough?) anyway.
I changed the naming convention slightly and plopped down a tarball
with some train wreck resembling a split up version of the thing nearby.
Against 2.5.73 virgin.

I've lost the wherewithal to list out the changes completely so only
the new bits are mentioned here. I wanted to get more done (e.g.
rmap_chain RCU, mapping->page_lock RCU), but other things are bugging
me at the moment, for instance bugs in what I've got thus far, and
those two are actually turning out to be hard to do. It looks like some
pages are getting into a weird state where swapoff(8) trips over the
things. I've got a workaround for the -EEXIST case (which should never
happen) in move_from_swap_cache(), but no idea what's going wrong apart
from a vague suspicion it has something to do with the usual suspect
i.e. Morton pages, or otherwise some stupid hamhandedness of mine in
the anobjrmap forward port. A beer at OLS says it's Morton pages.

I need to drop some crap which is stupid and has no positive effect,
like the partial kmap function inlining. 99% of everything they're
called on is actually in highmem so the in-line check for lowmem pages
just bloats code. I also magnified some rename action in the anobjrmap
stuff that shoves an mm in page->mapping that I should back off on and
save some diffsize by so doing. Dropping crud like that and merging
something useful for resource scalability instead, like shpte and
pagetable reclamation and swapping, would be more worthwhile. Or maybe
even properly splitting off pieces, getting them individually benched
properly, and shipping 'em back to -mm.

The edge doth bleed. You were warned.

+ anobjrmap 1-6:
	Hugh Dickins' old 2.5.65 stuff, brute-force forward ported and
	relatively certainly screwed up by yours truly. All bugs in
	this are my fault. No, I'm not trying to pick on Hugh, this
	just happens to be useful like various of his other patches. =)
	I changed the anonmm stuff to just chain mm's against a fresh
	struct anon; I didn't like the mixing of head and element.
	pte_chains are wiped entirely off the map. Some equivalent
	exists for rare cases where they're needed, but is utterly
	invisible in slabinfo and the functions manipulating them are
	yet to register a single profile hit. Maybe I goofed and
	they're not being called. At any rate I like the low overhead.

+ inline rmap functions' fast paths
	Anobjrmap made them small enough to inline. Unsurprisingly, it
	made certain benchmarks slightly faster. They obviously
	vaporized from profiles, which should make various people cheer.
	Unfortunately, you can still find the test_and_set_bit() locking
	in instruction-level profiles, which is what I wanted RCU to
	kill off for me on these things.

+ spinline + inline atomic_dec_and_lock()
	Despite being ultra-stupid, the atomic_dec_and_lock() inlining
	was the source of a few bugs. It could probably be done more
	cleanly, too. I'm thinking of making spinline mandatory. I see
	zero benefit from the lock sections (i.e. no spinline degradation).

+ RCU mapping->i_shared_sem
	Convert it to RCU from a semaphore. Unsurprisingly faster
	on bigboxen. No idea why it was a semaphore to begin with,
	objrmap got down() pileups on the thing that blew major goats.
	down() vaporized from my profiles after crowbarring this in.
	This RCU stuff is easy. It worked the first time.

+ RCU anon->lock
	Well, the lock was introduced by the anobjrmap bits, but RCU it
	anyway. No tangible benefit or harm on the benchmarks I ran
	apart from giving me the warm fuzzies. I should probably bench
	something that does a large number of fork()'s without an exec()
	and then goes into page replacement on 8x+ SMP to get an idea
	of how worthwhile this is. I don't know of such a benchmark
	that isn't a contrived microbenchmark offhand (maybe the entire
	scenario is contrived?) but I think it's just the Right Thing
	To Do (TM) and it saves some atomic operations. ->i_shared_sem
	was so easy I got cocky and had to plop down 3 or 4 bugfix
	pieces in the split out patches after this one because I
	screwed this up mightily with various truly trivial bogons at
	first (actually mostly unrelated to RCU except for one). It
	should be fine in and of itself now, of course.

-- wli

^ permalink raw reply	[flat|nested] 2+ messages in thread