[Bug 35798] 8ms latency when process with lots of swapped memory

[Victor Luchits]

Public bug reported:
https://launchpad.net/malone/bugs/35798

Affects: linux-meta linux-image-386 (Ubuntu)
       Severity: Normal
       Priority: (none set)
         Status: Unconfirmed

Description:
Don't know what package this bug belongs to, so I'm filing it here..

Originally submitted by Lee Revell. The patch went into 2.6.16 kernel and should probably backported to Dapper 2.6.15 kernel. Here's the summary:
http://kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commit;h=6f5e6b9e69bf043074a0edabe3d271899c34eb79

2.6.15 introduced a latency regression when unmapping: in accounting the
zap_work latency breaker, pte_none counted 1, pte_present PAGE_SIZE, but a
swap entry counted nothing at all.  We think of pages present as the slow
case, but Lee's trace shows that free_swap_and_cache's radix tree lookup
can make a lot of work - and we could have been doing it many thousands of
times without a latency break.

Move the zap_work update up to account swap entries like pages present.
This does account non-linear pte_file entries, and unmap_mapping_range
skipping over swap entries, by the same amount even though they're quick:
but neither of those cases deserves complicating the code (and they're
treated no worse than they were in 2.6.14).