- User Since
- Dec 14 2014, 5:52 AM (300 w, 5 d)
All of my recent amd64 comments apply here as well.
Suppose I'm a ZFS user and I start a bhyve VM with a large guest-physical memory and the -S option. My impression is that it is not unusual for the ARC to consume greater than 20% of physical memory.
Sat, Sep 5
You should also look at buf_ring_dequeue_mc(). It has similar problems. In fact, it never establishes a synchronizes-with relationship with the producer because the acquire is performed on the wrong field.
Thu, Sep 3
Wed, Sep 2
Mon, Aug 31
Sun, Aug 30
I'm trying to finish my final review of this change today.
I would take a "wait-and-see" approach to allocating the last available bit. Later adding that bit to the page size field isn't going to break any code written to this proposed 2-bit field.
Sat, Aug 29
Fri, Aug 28
Thu, Aug 27
Wed, Aug 26
Other than the potential overallocation in vm_reserv_startup(), I think that this is fine.
Tue, Aug 25
I have suggested to dougm@ that he evaluate reordering the array as a treap where the priority is based on the size of the segment.
Kostik, Mark, do you know of any machines with more segments?
I'm curious to see the output from "sysctl vm.phys_segs" on this machine.
Sun, Aug 23
I haven't had the time to do a careful, line-by-line review, but at a high level the approach looks okay.
Sat, Aug 22
Aug 17 2020
Aug 15 2020
Just an observation, not a request for further changes: I think that we could do better in terms of exploiting type stability on allocation of a vmspace. For example, I don't see why we explicitly set the vm_map's pmap field to NULL on deallocation and reinitialize it on allocation. Although the type of pmap may change on amd64 when recycling a vmspace, the vm_map will always be using the same storage for the pmap. Similarly, fields such as root, header.left, and header.right shouldn't require reinitialization.
Aug 13 2020
I agree with Kostik. Please go ahead and commit the pipe changes.
Aug 12 2020
I'll go a step further and question the point of even having a zone for the maps. Once upon a time, there were user-space "share" maps, but once those were eliminated and "regular" maps were embedded in the vmspace, supporting dynamic allocation of maps stopped being necessary.
Aug 7 2020
I'll give the pv entry reclamation code a careful reading tomorrow.
Aug 6 2020
Jul 29 2020
Jul 28 2020
(My questions are all unrelated to the direct purpose of the change.)
Jul 25 2020
Jul 23 2020
I'm convinced that replacing red-black trees with wavl trees is reasonable. There is barely even a trade-off between them. Wavl trees are either equal to or better than red-black trees in almost all respects. In the type of use case that actually favors red-black trees, i.e., no lookups, just random inserts and removes, the performance advantage for red-black trees that Doug reported was slight, about 2-3%. On the other hand, in a lookup-heavy workload the performance advantages of wavl trees were much more significant.
Jul 20 2020
The current third paragraph of the summary should be the second paragraph. The current second and fourth paragraphs should be merged. Then, it's no longer necessary for the current fourth paragraph to say, "while no insertion adjusts the tree too much".
Jul 19 2020
"... but the balance of the tree can start to get red-blackier." -> "but the balance of the tree can decay to that of a red-black tree."
"They have all the advantages of AVL trees ..." -> "They have the stricter balance of AVL trees ..."
Jul 17 2020
Here is what I would suggest for quickly getting "rank-balanced" out of the way and moving on to the more important part, the properties of "WAVL" trees:
Jul 16 2020
I think that you are trying to emulate the style of the original text describing red-black trees, and I think that you should break away from that style. Specifically, don't start with low-level definitional details. With red-black trees those details are so short that typical readers will stick around to the end of the text that says what they want to know in deciding to use red-black trees versus something else. For better or worse, those details are not so short for WAVL. So, you need to restructure the text to summarize the case for WAVL trees in the first paragraph, specifically, that they equal or dominate red-black trees in every dimension. In particular, you never explicitly say that WAVL insertion has the same complexity as red-black insertion both in the overall sense and in terms of rotations yet achieves better balance.
Jul 12 2020
Jul 11 2020
Jul 10 2020
Jul 9 2020
I have two comments.
I would encourage you to create a followup patch that provides an overview of the various TLB management implementations. I've got time now to help with refining the text if you can generate a first draft.
Jul 7 2020
Jul 6 2020
Jun 27 2020
Jun 26 2020
Jun 22 2020
Jun 19 2020
Jun 9 2020
May 13 2020
May 10 2020
On a barely related note, I wondered if you or Mark had observed whether the recently committed update to jemalloc has "fixed" the horrific anonymous memory fragmentation that occurs with applications like clang that mmap() a lot of files.
We configure x86 CPUs to use cached accesses to page table structures,
and TLB miss is not too awful from performance PoV if page table itself
is cached. More, I suspect that most gain from the superpages comes from
the fact that we are able to use more TLB entries, not because one entry
can serve more VA.
Apr 27 2020
Apr 23 2020
Apr 20 2020
Mar 13 2020
Feb 29 2020
The _NOFREE reminds me that we still need a way to segregate _NOFREE allocations in physical memory. Such segregation would most likely provide contiguity inherently.
Feb 25 2020
Is your overall strategy to incrementally replace PMAP_ASSERT_STAGE1(pmap)'s by correct handling of stage 2 PTE?