Accidentally created
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 18 2023
In D39661#902586, @mav wrote:I have no objections in general, if you find it useful, just a few on the implementation.
Handled by commit e06874f3f6d1f
D39660 takes care of this in a better way.
This looks like a much better solution, thanks!
In D39637#902426, @kib wrote:Ifuncs were supposed to be resolved only once, same as for userspace. Second (late) resolution is a sort of hack.
That said, I do not see a need to waste kernel memory to remember the status there. There is no problem with tunable changing or disappearing, because all kernel ifunc resolvers are called long before userspace is started.
In D39637#902426, @kib wrote:In D39637#902419, @stevek wrote:In D39637#902418, @kib wrote:I do not like adding static for that. Could you do this instead?
Then you spend take the cost of re-evaluating the tunable each time that a ifunc needs to be evaluated.
The tunable is supposed to be a one-and-done thing.Ifuncs were supposed to be resolved only once, same as for userspace. Second (late) resolution is a sort of hack.
That said, I do not see a need to waste kernel memory to remember the status there. There is no problem with tunable changing or disappearing, because all kernel ifunc resolvers are called long before userspace is started.
In D39639#902347, @emaste wrote:IMO this is fine, but also ${.ALLSRC} should only ever be ${FULLKERNEL} so not sure how you'd get this case.
In D39637#902418, @kib wrote:I do not like adding static for that. Could you do this instead?
Added closing quote per review comments
In D39635#902089, @imp wrote:Also, this is starting to get a little lengthy for a quote. Do the standards say you need permission to quote? If not, I think it's short enough to be fine. If it does, however, we may look to trim a bit.
Apr 17 2023
Updated commit log and source file comments
Apr 16 2023
In D39593#901233, @mjg wrote:fdt_nfiles should probably become unsigned instead and whatever which does not already (u_int)fd should start doing it
what compiler are you using?
Apr 15 2023
Apr 14 2023
Apr 12 2023
Mar 14 2023
Jan 5 2023
Dec 28 2022
Dec 22 2022
In D37753#858859, @pstef wrote:Could the commit message provide some reasoning about why this can be useful, what advantages it provides compared to mdmfs (wich compressed image), and why it makes sense to do this in kernel as opposed to fusefs? Thanks.
Dec 6 2022
This matches what we use locally at Juniper
Dec 5 2022
Looks reasonable to me and what we use already at Juniper.
Jan 6 2022
In D33761#763599, @manu wrote:
Dec 29 2021
Dec 20 2021
Add db_pager_quit checks per review comments
Dec 17 2021
Dec 10 2021
Aug 27 2021
Aug 20 2021
Jul 21 2021
We have been using KSTACK_PAGES=4 in our Cortex-A9-based switches (with 2GiB RAM) for a number of years now.
During the platform bringup days, before bumping up the KSTACK_PAGES, we were hitting cases where we were running out of stack space and getting all sorts of wonderful odd crashes happening.
Apr 30 2021
Seems okay to me, but @sjg would be the best to look at it, since the loader veriexec bits are his pet project.
Apr 9 2021
In D29531#664852, @me_freebsd_mathieu.digital wrote:So if you tell us you have no idea how long it'll take before you get the green light, I'd be for merging that one and for your review to update/rewrite it.
If you tell us you'll have something before summer, I'd say let's wait for you.
Apr 8 2021
As I mentioned previously, my employer has contracted work to bring this driver to a full implementation. An initial draft is under review internally and a Phabricator review is queued up once we give the green light. That is why I suggested holding off on this version of the patch.
In D29531#664242, @me_freebsd_mathieu.digital wrote:Clearly, ACPI-fast (which is the default) is at the bottom of the pile: I get less than half the bandwidth from the block device compared to what I get with kvmclock. TSC-low is the best of them all but I assume there's a reason it's rated so low (surprisingly it's better that i8254 which is rated higher).
Apr 7 2021
As I mentioned previously, the other thing to consider when using kvmclock in the current patch is the need for a system call for clock_gettime(), gettimeofday(), etc.
In D29531#663896, @imp wrote:A number of people are reporting problems with zfs scrub w/o this fix that they say is corrected by this, so there's some desirer to have it in the tree. Do you know if these setups are common? Or do you have a notion of why these results have been reported in light of this instability?
Apr 6 2021
My employer has contracted work to bring this driver to a full implementation, including adding VDSO support for kvmclock. Currently, with the kvmclock driver as in the original reviews and this one, user space processes end up needing to do a system call for gettimeofday and clock_gettime. With the VDSO support, the clock will be able to be kept in sync via the shared memory pages and avoid the system call overhead.