Page MenuHomeFreeBSD

alc (Alan Cox)
User

Projects

User Details

User Since
Dec 14 2014, 5:52 AM (239 w, 4 d)

Recent Activity

Tue, Jul 16

alc committed rS350021: Revert r349973. Upon further reflection, I realized that the comment.
Revert r349973. Upon further reflection, I realized that the comment
Tue, Jul 16, 3:09 AM
D20965: Propagate attribute changes during demotion. is now accepted and ready to land.
Tue, Jul 16, 1:49 AM

Mon, Jul 15

alc added inline comments to D20833: factor out common wiring code.
Mon, Jul 15, 8:35 PM
D20907: Implement software AF and DBM management for arm64. is now accepted and ready to land.

Without the patch, a "buildworld" generates the following counts:

vm.pmap.l2.promotions: 113985
vm.pmap.l2.p_failures: 1
vm.pmap.l2.mappings: 59015
vm.pmap.l2.demotions: 11697
vm.reserv.reclaimed: 0
vm.reserv.partpopq:
DOMAIN    LEVEL     SIZE  NUMBER
Mon, Jul 15, 2:52 PM
alc added a comment to D20907: Implement software AF and DBM management for arm64..

The changes look okay. I've booted a kernel with this latest version of the patch, and I'm testing it overnight. I'll let you know if the promotion count changes significantly.

Mon, Jul 15, 5:50 AM

Sun, Jul 14

alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Sun, Jul 14, 11:19 PM
alc added a comment to D20863: prototype for trimming.

I think that swapgeom_strategy() should be made to handle a BIO_DELETE just like a BIO_WRITE.

Sun, Jul 14, 9:31 PM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Sun, Jul 14, 9:16 PM
alc added inline comments to D20863: prototype for trimming.
Sun, Jul 14, 8:52 PM
D20926: Fix pmap_ts_referenced()'s reference counting on RISC-V. is now accepted and ready to land.
Sun, Jul 14, 4:54 PM

Sat, Jul 13

alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Sat, Jul 13, 11:12 PM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Sat, Jul 13, 10:43 PM
alc added inline comments to D20625: clarify reserv_test_config.
Sat, Jul 13, 5:54 PM
alc added a comment to D20907: Implement software AF and DBM management for arm64..

On amd64, we've done a bit of testing here with https://github.com/GraphChi/graphchi-cpp doing pagerank, and we've seen a lot of vm object lock contention and a little pmap lock contention. In regards to the pmap lock, some of the functions showing up in the lock profile, e.g., pmap_is_prefaultable(), really only need a read lock on the pmap. In other words, I think that there may be motivation beyond accessed and dirty bit emulation to consider changing the pmap lock to a rw lock.

Sat, Jul 13, 5:20 PM
D20907: Implement software AF and DBM management for arm64. is now accepted and ready to land.

I've been testing this change in combination with the just committed r349975, and I haven't seen any suspicious behavior. Moreover, in regards to reviewing this patch, I've read over it multiple times and I'm past the point of diminishing returns. So, I'm going to suggest that you commit it.

Sat, Jul 13, 4:58 PM
alc committed rS349975: Revert r349442, which was a workaround for bus errors caused by an errant.
Revert r349442, which was a workaround for bus errors caused by an errant
Sat, Jul 13, 4:32 PM
alc committed rS349973: Remove a stale comment..
Remove a stale comment.
Sat, Jul 13, 3:53 PM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Sat, Jul 13, 3:25 AM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Sat, Jul 13, 2:45 AM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Sat, Jul 13, 2:35 AM

Fri, Jul 12

alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Fri, Jul 12, 4:15 PM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Fri, Jul 12, 3:42 AM

Thu, Jul 11

alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Thu, Jul 11, 8:41 PM
alc accepted D20893: Fix a next_leaf bug.
Thu, Jul 11, 8:00 PM
alc added inline comments to D20893: Fix a next_leaf bug.
Thu, Jul 11, 7:41 PM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Thu, Jul 11, 1:15 PM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Thu, Jul 11, 12:55 PM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Thu, Jul 11, 12:43 PM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Thu, Jul 11, 6:13 AM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Thu, Jul 11, 5:48 AM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Thu, Jul 11, 3:05 AM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Thu, Jul 11, 3:00 AM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Thu, Jul 11, 2:55 AM
alc committed rS349905: According to Section D5.10.3 "Maintenance requirements on changing System.
According to Section D5.10.3 "Maintenance requirements on changing System
Thu, Jul 11, 2:43 AM
Herald added a reviewer for D20904: Add an instruction barrier to pmap_activate(): manu.
Thu, Jul 11, 2:43 AM

Wed, Jul 10

alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Wed, Jul 10, 10:30 PM
alc added inline comments to D20907: Implement software AF and DBM management for arm64..
Wed, Jul 10, 10:00 PM
alc updated subscribers of D20904: Add an instruction barrier to pmap_activate().
Wed, Jul 10, 7:26 PM
alc added a comment to D20904: Add an instruction barrier to pmap_activate().

efi_arch_enter() and _leave() have the isb following the TLB invalidation.

Wed, Jul 10, 3:47 PM
D20904: Add an instruction barrier to pmap_activate() now requires review to proceed.

Add the isb instruction to efi_arch_enter() and efi_arch_leave().

Wed, Jul 10, 3:43 PM
alc created D20904: Add an instruction barrier to pmap_activate().
Wed, Jul 10, 3:15 PM

Tue, Jul 9

alc committed rS349866: Introduce pmap_clear(), which zeroes a page table entry, and use it, instead.
Introduce pmap_clear(), which zeroes a page table entry, and use it, instead
Tue, Jul 9, 8:29 PM

Sun, Jul 7

alc added inline comments to D20863: prototype for trimming.
Sun, Jul 7, 8:18 PM
alc added inline comments to D20863: prototype for trimming.
Sun, Jul 7, 5:46 PM
alc accepted D20871: Fix comment after r349791.
Sun, Jul 7, 6:48 AM
alc committed rS349798: Three changes to pmap_enter():.
Three changes to pmap_enter():
Sun, Jul 7, 6:07 AM
alc added inline comments to D20863: prototype for trimming.
Sun, Jul 7, 2:29 AM
alc added a comment to D20863: prototype for trimming.

Something less obviously blocking, though I'm sure some flags are set wrong and the wait for an available write resource (nsw_wcount_async) is unacceptible. There must a queue somewhere I could stick that task in, waiting for writing to be okay again.

Sun, Jul 7, 2:23 AM

Sat, Jul 6

alc added inline comments to D20863: prototype for trimming.
Sat, Jul 6, 7:38 PM
alc added inline comments to D20833: factor out common wiring code.
Sat, Jul 6, 5:42 PM
alc added a comment to D20863: prototype for trimming.

To be clear, I am not arguing that the alternative design is the better one. Only that there are plausible alternatives, and that we shouldn't start making incremental changes until we have evidence for following one approach or the other.

Sat, Jul 6, 5:33 PM
alc added inline comments to D20847: fix style(9) violations involving division by PAGE_SIZE.
Sat, Jul 6, 5:24 PM
alc added inline comments to D20833: factor out common wiring code.
Sat, Jul 6, 5:05 PM
alc added inline comments to D20833: factor out common wiring code.
Sat, Jul 6, 4:53 PM
alc added a comment to D20863: prototype for trimming.

I would really like to see a complete prototype before we start committing piecemeal changes. Largely, because it is not clear to me that a "two cursors"-based approach is the right design. Alternatively, when trim is enabled, we could introduce a "coalescing queue" in front of the blist_free() calls. In other words, when trim is enabled, where blist_free() is currently called, we would simply enqueue the block numbers. When the number and/or size of the entries in the coalescing queue crosses some threshold, we would wake up a helper thread that issues trim operations for some of the entries and calls blist_free() on the corresponding blocks after the trim operation has completed. Situations where the number of free blocks in the blist falls below a threshold, may also require special handling, possibly even skipping the trim operation. The unknown with this alternative approach is how large the coalescing queue would be, or really how much memory we would allow it to consume, in order for it to be effective.

Sat, Jul 6, 4:27 PM
alc added reviewers for D20847: fix style(9) violations involving division by PAGE_SIZE: kib, markj.
Sat, Jul 6, 3:41 PM

Fri, Jul 5

Herald added a reviewer for D20848: Restructure cache_handle_range to avoid unnecessary barriers: manu.
Fri, Jul 5, 8:01 PM
alc committed rS349768: Restructure cache_handle_range to avoid repeated barriers. Specifically,.
Restructure cache_handle_range to avoid repeated barriers. Specifically,
Fri, Jul 5, 8:01 PM
alc accepted D20635: release multiple swap blocks at a time in swp_pager_force_pagein.
Fri, Jul 5, 4:27 PM
D20635: release multiple swap blocks at a time in swp_pager_force_pagein is now accepted and ready to land.
Fri, Jul 5, 5:24 AM
alc committed rS349760: Merge r349526 from amd64. When we protect an L3 entry, we only call.
Merge r349526 from amd64. When we protect an L3 entry, we only call
Fri, Jul 5, 5:23 AM

Thu, Jul 4

alc added a comment to D20833: factor out common wiring code.

I would refactor this differently. I would create a helper function to handle the "in transition" case, in other words, the body of the following "if" statement.

                if (entry->eflags & MAP_ENTRY_IN_TRANSITION) {
                        /*                                                                                                                                                          
                         * We have not yet clipped the entry.                                                                                                                       
                         */
...
                }
Thu, Jul 4, 10:07 PM
D19247: Merge hold_count into wire_count. is now accepted and ready to land.
Thu, Jul 4, 8:55 PM
alc added a comment to D20850: remove gotos from vm_map_unwire.

I don't feel strongly enough about this issue to request that the change be reverted.

Thu, Jul 4, 8:26 PM
D20859: Don't call vm_reserv_free_page() if PG_PCPU_CACHE is set. is now accepted and ready to land.
Thu, Jul 4, 8:08 PM
D19247: Merge hold_count into wire_count. is now accepted and ready to land.

I will be very happy to see this change committed. It's something that I've wanted to see happen for many years.

Thu, Jul 4, 7:54 PM
alc added a comment to D20850: remove gotos from vm_map_unwire.

I don't like this change. In cases like this, specifically error handling in complex code, the goto is easier to understand (and very common in kernel code). A "break;" is context sensitive, i.e., I have to determine whether I am a nested loop.

Thu, Jul 4, 7:39 PM
alc added inline comments to D20855: replace 'goto' with 'else' in vm_map_wire_locked..
Thu, Jul 4, 7:10 PM
alc added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

Peter, can you please retest this patch? I think that all of the open issues have been addressed.

Thu, Jul 4, 6:41 PM
D20849: drop a temp variable from vm_map_insert is now accepted and ready to land.
Thu, Jul 4, 6:25 PM
alc updated subscribers of D20848: Restructure cache_handle_range to avoid unnecessary barriers.

Just an FYI, when I modified arm64_icache_sync_range() to do the range-based "ic" operations, instead of flushing the entire L1 I-cache, performance got very slightly worse. I was somewhat surprised by this result.

Thu, Jul 4, 3:32 PM
alc updated the test plan for D20848: Restructure cache_handle_range to avoid unnecessary barriers.
Thu, Jul 4, 3:03 AM
alc created D20848: Restructure cache_handle_range to avoid unnecessary barriers.
Thu, Jul 4, 3:00 AM

Wed, Jul 3

alc added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

I would ask Peter to retest this latest version, and if all is well add Kostik and Mark as reviewers. I am ready to rubber-stamp this version unless Peter turns up a problem.

Wed, Jul 3, 10:57 PM
D20845: Remove a goto from vm_map_wire_locked is now accepted and ready to land.
Wed, Jul 3, 10:35 PM
alc added a reviewer for D20635: release multiple swap blocks at a time in swp_pager_force_pagein: alc.
Wed, Jul 3, 6:50 PM
alc added inline comments to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.
Wed, Jul 3, 6:49 PM

Tue, Jul 2

alc committed rS349618: Implement pmap_copy(). (This includes the changes applied to the amd64.
Implement pmap_copy(). (This includes the changes applied to the amd64
Tue, Jul 2, 11:03 PM
Herald added a reviewer for D20790: Implement pmap_copy() for arm64: manu.
Tue, Jul 2, 11:03 PM
alc added inline comments to D20790: Implement pmap_copy() for arm64.
Tue, Jul 2, 7:27 PM
alc added a comment to D19247: Merge hold_count into wire_count..

Are all of the prerequisite changes for this patch now committed?

Tue, Jul 2, 7:25 PM
alc added a comment to D20763: Add PG_CACHE_ALLOC..
In D20763#451040, @alc wrote:

Sorry, I wasn't clear. There are two aspects to Jeff's proposal: (1) inverting the sense of the flag and (2) making it an "aflag" so that it can be modified asynchronously. I don't think (1) helps. As I described, for breaking reservations, it would be a pessimization. However, I think (2) might prove beneficial. For example, it's not obvious to me that we could safely clear PG_CACHE_ALLOC asynchronously on an allocated page without the page and/or object lock.

Ok. I propose that we commit this diff, add a page cache for VM_FREEPOOL_DIRECT, and use PG_CACHE_ALLOC to skip vm_reserv_free_page() calls in vm_page_free_prep(). Then we can try and come up with a policy for reserving contiguous memory for _NOFREE allocations, which might involve making PG_CACHE_ALLOC an aflag.

Tue, Jul 2, 3:54 PM
alc added a comment to D20763: Add PG_CACHE_ALLOC..
In D20763#450948, @alc wrote:
In D20763#450130, @jeff wrote:

I wrote an experimental patch last year to segregate NOFREE zones using a new vm_phys pool. You can find it at D16620. It's better than nothing. :-) However, its primary shortcomings are that (1) it only applies to architectures with a direct map and (2) that pools only provide "soft" segregation. In other words, I don't think vm_phys pools are the right solution.

For (1), could we use a separate vmem arena for _NOFREE allocations like we do for M_EXEC?

That's not as good, since it will only provide physical contiguity so long as there are free reservation-sized chunks of physical memory.

Tue, Jul 2, 5:05 AM
alc added a comment to D20763: Add PG_CACHE_ALLOC..
In D20763#450948, @alc wrote:
In D20763#450130, @jeff wrote:

I wrote an experimental patch last year to segregate NOFREE zones using a new vm_phys pool. You can find it at D16620. It's better than nothing. :-) However, its primary shortcomings are that (1) it only applies to architectures with a direct map and (2) that pools only provide "soft" segregation. In other words, I don't think vm_phys pools are the right solution.

For (1), could we use a separate vmem arena for _NOFREE allocations like we do for M_EXEC?

Allow me to suggest a slight alternative to the above that I think will cover more cases. If we invert the sense of the flag and put it in an atomic field we can then set it anywhere that we discover a page that is creating fragmentation or may do so. For example, in the defrag code we could discover a single page in a superpage that is presently allocated and set the bit. We would additionally set the bit whenever we break a reservation to allocate a page because we are low on memory, which is what this case handles.

Yes, I think something like this flag could prove useful. However, in regards to reservations, when we break a reservation, the code is actually "clever" enough that it does not touch every vm_page structure. From the starting physical address of the reservation and the reservation's popmap we figure out the maximal order chunks of pages to reinsert into the buddy queues, and so vm_phys never winds up coalescing any of the pages from a broken reservation. Setting this proposed flag would introduce new vm_page structure touches.

I don't quite see how inverting the sense would make it possible to handle more cases. With this diff, we free to the per-CPU cache if and only if PG_CACHE_ALLOC is set. Defragmentation code, upon encountering an allocated page in an otherwise free 2MB chunk, could clear PG_CACHE_ALLOC to ensure that the page would bypass the per-CPU caches when it is freed by its owner. Today, vm_page_reclaim_run() frees pages directly to vm_phys and thus always bypasses the per-CPU cache, otherwise it would need to be updated by this diff.

Tue, Jul 2, 4:58 AM

Mon, Jul 1

alc added a comment to D20790: Implement pmap_copy() for arm64.

A kernel with this change has survived multiple, back-to-back "make -j8 buildworld"'s with no spurious bus errors.

Mon, Jul 1, 10:04 PM
alc committed rS349585: Tidy up pmap_copy(). Notably, deindent the innermost loop by making a.
Tidy up pmap_copy(). Notably, deindent the innermost loop by making a
Mon, Jul 1, 10:00 PM
alc closed D20812: Tidy up amd64's pmap_copy().
Mon, Jul 1, 10:00 PM
D20763: Add PG_CACHE_ALLOC. is now accepted and ready to land.
Mon, Jul 1, 8:49 PM
alc added a comment to D20763: Add PG_CACHE_ALLOC..
In D20763#450130, @jeff wrote:

My recollection is that when I implemented the cache there simply wasn't a lot of traffic for the other free pools and I didn't want to increase fragmentation. I have no objection to doing so now. I do believe we should have some separation for UMA NOFREE zones whether that is a different pool or some other layer I can not say.

Mon, Jul 1, 8:43 PM
alc added inline comments to D20812: Tidy up amd64's pmap_copy().
Mon, Jul 1, 3:44 PM
alc added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

Why is vm_object_pip_wakeup() no longer called?

Mon, Jul 1, 2:51 PM
alc added a comment to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.

Why is vm_pager_page_unswapped() no longer called?

Mon, Jul 1, 7:21 AM
alc added inline comments to D20635: release multiple swap blocks at a time in swp_pager_force_pagein.
Mon, Jul 1, 7:00 AM

Sun, Jun 30

D20790: Implement pmap_copy() for arm64 now requires review to proceed.

Sync with https://reviews.freebsd.org/D20812, which applies a bunch of style fixes and one micro-optimization to the amd64 pmap_copy().

Sun, Jun 30, 10:57 PM
alc added a comment to D20812: Tidy up amd64's pmap_copy().

More style fixes.

Sun, Jun 30, 10:36 PM
alc added inline comments to D20812: Tidy up amd64's pmap_copy().
Sun, Jun 30, 10:19 PM
alc added inline comments to D20812: Tidy up amd64's pmap_copy().
Sun, Jun 30, 10:01 PM
alc created D20812: Tidy up amd64's pmap_copy().
Sun, Jun 30, 9:30 PM
alc added inline comments to D20790: Implement pmap_copy() for arm64.
Sun, Jun 30, 4:25 PM

Sat, Jun 29

alc added inline comments to D20790: Implement pmap_copy() for arm64.
Sat, Jun 29, 5:37 PM