diff options
| author | Daniel Gerzo <danger@FreeBSD.org> | 2006-09-24 13:36:59 +0000 |
|---|---|---|
| committer | Daniel Gerzo <danger@FreeBSD.org> | 2006-09-24 13:36:59 +0000 |
| commit | ed2cda15f08a4bf8778140702b5837eb62cc3313 (patch) | |
| tree | 29de8515320dc20e9372b8a078cb5d0f9796210e | |
| parent | 5ec137126badd39a2e8d2dbad46f0de8e1cc3943 (diff) | |
Notes
| -rw-r--r-- | en_US.ISO8859-1/articles/vm-design/article.sgml | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/en_US.ISO8859-1/articles/vm-design/article.sgml b/en_US.ISO8859-1/articles/vm-design/article.sgml index 60d7fd3034..01fa36b51a 100644 --- a/en_US.ISO8859-1/articles/vm-design/article.sgml +++ b/en_US.ISO8859-1/articles/vm-design/article.sgml @@ -234,7 +234,7 @@ process will take a copy-on-write fault and duplicate the page in C2. The original page in B is now completely hidden since both C1 and C2 have a copy and B could theoretically be destroyed if it does not - represent a <quote>real</quote> file). However, this sort of optimization is not + represent a <quote>real</quote> file; however, this sort of optimization is not trivial to make because it is so fine-grained. FreeBSD does not make this optimization. Now, suppose (as is often the case) that the child process does an <function>exec()</function>. Its current address space @@ -766,7 +766,7 @@ of L1 cache. Generally the way this cache works is that each 128K block of main memory uses the <emphasis>same</emphasis> 128K of cache. If you access offset 0 in main memory and then offset - offset 128K in main memory you can wind up throwing away the + 128K in main memory you can wind up throwing away the cached data you read from offset 0!</para> <para>Now, I am simplifying things greatly. What I just described |
