- User Since
- May 16 2014, 7:29 PM (282 w, 2 d)
Fix the diff
Don't use config_intrhook_establish(), the mutex isn't initialized yet.
@kevans committed this in r352863 2 weeks ago.
I really like that you took the time to annotate the existing code. It's tough to read and understand it the first several times through.
Looks good for what we can do for now. I really should clean up the whole DPAA interface bits, so we don't need to do that loop. But since it's only executed on bootup, it's not a very high priority task.
Fri, Oct 11
Wed, Oct 9
Address @emaste's comments
Address andrew's feedback. Thanks!
Tue, Oct 8
Mon, Oct 7
Sun, Oct 6
Tue, Oct 1
This will simplify D21682 a bit, as well. PowerPC has sub-word atomics since PowerISA 2.06, so we'll need dual personality there.
Mon, Sep 30
Sat, Sep 28
Wed, Sep 25
Can you add a key/sentinel into the dump structure to say what pmap it's using? libkvm will need it for properly decoding addresses, and that differential will also need to be updated to use the key and select a backend.
Fri, Sep 20
Wed, Sep 18
This is very specific to AIM64 HPT. Can you rename it to kvm_..._hpt.c, or something, and add another key to the header to probe against for the particular pmap implementation? I'll want to add Book-E support, as well as AIM Radix when we do finally get radix stabilized.
Tue, Sep 17
Sat, Sep 14
Sep 13 2019
Sep 12 2019
This should be able to go in before flag day, there's nothing preventing it from working (we don't need linker support just for this, it's all in code).
Sep 10 2019
Sep 9 2019
Sep 6 2019
Only a trivial review so far.
I like it, except for the typo :)
@i_maskray.me, you're right. It should just be
Sep 5 2019
Can you instead add something like the following to crt1.c?
Address luporl's comments.
Sep 4 2019
Sep 2 2019
On Book-E it's already allocated out of KVA, as part of the bootstrap carving. Looks like on AIM I could just adjust virtual_avail as you mention in your comment in D21491, there would be up to 32MB (less 2 pages) slop, (15MB less 1 page on either side) which is probably fine on NUMA machines. But we do only have 32GB KVA available currently, and if the vm_page_array is ~3% of total memory, on a 256GB machine that's ~8GB, which is pretty big. I think I'd rather hold off on it until we either increase KVA or get actual working dump support.
@mjg glib does use fdwalk() if available, and emulates it where needed. This work I started specifically because I saw this same code flow in multiple ports.
Sep 1 2019
Address feedback. I think this is better overall, simplifies things.
Aug 31 2019
This change appears to give me a 15-20% improvement with building llvm on my Talos (144 thread POWER9). No change at all with buildworld.
Aug 28 2019
Aug 27 2019
Aug 26 2019
You're right, I don't know what I was thinking. The page_range change is the only thing needed from this diff.
Aug 25 2019
Aug 21 2019
Aug 20 2019
Aug 18 2019
Fix 32-bit build.
Aug 17 2019
It shouldn't be built for powerpc32, only powerpc64. However, it doesn't hurt anything, and is a good belt-and-suspenders change.
Aug 16 2019
Aug 15 2019
Address @kib's feedback. The man page will probably need more iterating, but I
think the code is correct. It may not be optimal, though.
Aug 14 2019
Don't call getpid(), we can pass 0 now.
Aug 13 2019
Add a new sysctl, kern.proc.fdmap.<proc>, to provide the bitmap. Walk the bitmap instead of the file descriptor list.
Aug 12 2019
Aug 11 2019
Aug 10 2019
Address @kib's feedback. Man page will probably require several iterations
to get right. It's still a little muddy.
Aug 9 2019
Aug 8 2019
Looks fine overall, just the one question. I just want to be sure this is thoroughly tested before it goes in, on the corner cases.
Looks good now.