No COW in Private VMA
In current Linux 2.6.16, Linux applies copy-on-write technical when application
issues CLONE_MM parameter to do_fork, as the result, it makes private VMA of a
process share its private pages with other process. It increases memory
subsystem complexity.
In fact, OS should be application-oriented, not standard-oriented. In most
cases, supporting POSIX thread model, vfork and evecve is enough to application.
In other words, we should focus on optimizing our system for the frequent cases,
that is, do copy-on-call when someone really calls fork with CLONE_MM.
No COW in private VMA makes a simple one-to-one relationship among its pte, its
private page and its swap_entry of a private VMA, we will benefit from the model
A new PTE type is introduced here before we go
struct UnmappedPTE {
present : 1; // = 0.
...;
pageNum : 20;
};
1) To swap daemon, we can give a fairer opportunity to every private page. As
I've suggested swap daemon should swap out pages based on VMA instead of memory
page array. So we do the steps listed below to every pte of a private VMA
a) Convert the pte to UnmappedPTE type, that doesn't free the private page
at all, UnmappedPTE::pageNum holds a trace of its private page.
b) Allocate a swap entry for the private page of the pte and page-out it,
remember do the job on current pte and its following ptes together, I've
explained the virtue.
c) OK, it's still untouched, reclaim the private page, convert the pte to
SwappedPTE type.
The flow is better than the implementation of current Linux, I think.
2) We can economize a litter memory. Current swap space includes two parts, one
is swap_info_struct, its responsibility is tracing physical swap area by short
swap_info_struct::swap_map array. Now, it should be a bit array; Another is an
address_space structure, which is used by process to test whether its swap pages
have been read in memory. Now, it should be discarded, every swap page once is
read in, it's linked with its pte by UnmappedPTE.
Note, No COW in PrivateVMA is a bigger improvement.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]