Re: [PATCH 4/10] alternate 4-level page tables patches

[William Lee Irwin III <wli@holomorphy.com>]

William Lee Irwin III wrote:
>> If clear_page_tables() implemented perfect GC.

On Sat, Dec 18, 2004 at 10:55:58PM +1100, Nick Piggin wrote:
> Oh... well it does perfectly free memory in the context of what ranges
> have been previously cleared with clear_page_tables. So that doesn't
> free you from the requirement of calling clear_page_tables at some
> point.
> I suspect though, you are referring to refcounting, in which case yes,
> GC could probably be performed at unmap time, and clear_page_tables
> could disappear. I still think it would be too costly to refcount down
> to the pte_t level, especially SMP-wise.... but I'm just basing that
> on a few minutes of thought, so - I don't really know.

vmas are unmapped one-by-one during process destruction.


William Lee Irwin III wrote:
>> Counterexamples would be illustrative.

On Sat, Dec 18, 2004 at 10:55:58PM +1100, Nick Piggin wrote:
> Oh, just workloads where memory is fairly dense in virtual space, and
> not shared (much). Non-oracle workloads, perhaps? :)
> Seriously? On my typical desktop, I have 250MB used, of which 1MB is
> page tables, I suspect this is a pretty typical ratio on desktops,
> but I have less experience with high end database servers and that type
> of stuff.
> I was hoping you could provide an example rather than me a counter ;)

Page replacement is largely irrelevant to databases. Administrators
etc. rather go through pains to avoid page replacement and at some
cost. They rather reclaim when page replacement occurs. More beneficial
for databases would be increasing the multiprogramming level a system
can maintain without page replacement or background data structure
reclamation.  This is, of course, not to say that databases can
tolerate leaks or effective leaks of kernel memory or data structures.

Effective eviction of process data is far more pertinent to laptops and
desktops, where every wasted pagetable page is another page of
userspace program data that has to be swapped out and another write to
a disk spun by a battery with a limited lifetime (though the timer is
probably a larger concern wrt. battery life). Idle processes are likely
to be the largest concern there. The kernel's memory footprint
is always pure overhead, and pagetables are a very large part of it.

(a) idle bloatzilla
(b) idle mutt
(c) idle shells
(d) numerous daemons started up by initscripts and rarely ever invoked


-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>