- fix numbering
- pull in cryptocheck change
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 13 2018
Dec 12 2018
Dec 11 2018
Nov 27 2018
Nov 25 2018
In D18327#389052, @markj wrote:it's a last resort mechanism, as opposed to the regular PID-controller pagedaemons
It should run regularly (with a 10s period) whenever the pagedaemon is attempting to reclaim pages.
Is there a specific application you're using to trigger this problem? I've never seen a large number of pages be wired by the TTM; maybe there's a GEM object leak? Are you using amdgpu or radeonkms?
Nov 21 2018
- respond to feedback
- further changes for 4.18
Nov 19 2018
+1 I was just observing the need for this last night.
Nov 14 2018
Nov 13 2018
Why isn’t this hit elsewhere? Are you compiling without EARLY_AP ?
Nov 9 2018
Nov 6 2018
Nov 5 2018
Nov 4 2018
Odd. It applied cleanly this time. I'll commit after a tinderbox run.
Nov 3 2018
After this change sampling under load is truly terrible - rejecting 99+% of samples:
+ pmcstat -S unhalted_core_cycles -O ppid.pmcstat sleep 10 + pmcstat -R ppid.pmcstat -z100 -G ppid.stacks CONVERSION STATISTICS: #exec/elf 1 #samples/total 566445 #callchain/dubious-frames 565995
Nov 2 2018
This needs to be multiple reviews.
Please separate out the de-inlining in to a separate review. We can commit that as the major chunk and then the other changes will be easier to review.
sorry didn't mean to change the title - just add markj
Oct 29 2018
In D17401#379234, @somalapuram_gmail.com wrote:In D17401#373713, @mmacy wrote:In D17401#373706, @somalapuram_gmail.com wrote:In D17401#373648, @mmacy wrote:Do you need this in for the 12 release? I can do that, it just means some more hoops for me jump through.
I am unable to commit (svn commit). (https://wiki.freebsd.org/Phabricator)
Do I have to commit or it will be automatically do ?? do I miss any steps ??
svn-commit.tmp: 36 lines, 1596 characters.
svn: E170001: Commit failed (details follow):
svn: E170001: Authorization failed
svn: E170001: Your commit message was left in a temporary file:
svn: E170001: '/usr/home/amar/freebsd_svn/freebsd_head/svn-commit.tmp'Someone with a commit bit needs to do it
Hi Macy can you help me to commit this changes..
Also worth looking at:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-June/174985.html
I just rebased to today's HEAD from that of the 6th. This change makes my system unbootable. I haven't delved in to it, but my guess is I don't have enough contiguous memory below the limit (my system has 512GB)
Oct 26 2018
@rajfbsd_gmail.com I can't actually apply this to a release branch (11.2) I can only commit to stable/11 (from which 11.3 will come) where it looks like parts of this have already been MFC'd. The patch doesn't actually apply cleanly there. Could you please update it to apply to the stable/11 branch?
In D17682#378334, @arichardson wrote:Yes, the current set of patches required (for macos and linux) can be seen here: https://github.com/arichardson/freebsd/tree/crossbuild-aug2018?files=1
Oct 25 2018
should we abandon?
Already effectuated in HEAD
It looks fine to me. I'll commit it as soon as I can.
In D17593#375500, @bz wrote:In D17593#375498, @mmacy wrote:Is this in response to an observed bug? This is adding a lot of complexity when we can simply validate the result
The complexity mostly comes from the fact that we can (and do) now properly lock in the inp when going over the lists (which we couldn't before due to lock order) and with that are less prone to races. Hence this is not just about validating the inp is not FREED but one patch without the other half would make it worse. I can break them up into two if that makes it easier to review/progress.
@hselasky this is getting super complicated - how much can we avoid by replacing the epoch_wait()+free() with an epoch_call()?
@hselasky have you had pho@ test this change?
LGTM. Are you cross-building from OSX?
Oct 18 2018
Oct 17 2018
Is this in response to an observed bug? This is adding a lot of complexity when we can simply validate the result
Oct 12 2018
Oct 11 2018
In D17401#373706, @somalapuram_gmail.com wrote:In D17401#373648, @mmacy wrote:Do you need this in for the 12 release? I can do that, it just means some more hoops for me jump through.
I am unable to commit (svn commit). (https://wiki.freebsd.org/Phabricator)
Do I have to commit or it will be automatically do ?? do I miss any steps ??
svn-commit.tmp: 36 lines, 1596 characters.
svn: E170001: Commit failed (details follow):
svn: E170001: Authorization failed
svn: E170001: Your commit message was left in a temporary file:
svn: E170001: '/usr/home/amar/freebsd_svn/freebsd_head/svn-commit.tmp'
Oct 10 2018
Do you need this in for the 12 release? I can do that, it just means some more hoops for me jump through.
In D17503#373585, @jtl wrote:In D17503#373574, @sbahra_repnop.org wrote:In D17503#373529, @jtl wrote:In D17503#373490, @sbahra_repnop.org wrote:See previous note in D17492 regarding the assumption that write-side functions are *not* called with-in a read-side critical. Does FreeBSD require that this is permitted?
See my comments in that review.
Regardless of whether that is true, it seems like this change would still be safe. Do you agree?
Is it expected by the kernel that ck_epoch write-side functions are safe to call on records that are already in a read-side critical section?
Helping me understand the intended use-case will allow me to answer accurately. There is further validation needed beyond poll.See related comments in D17492. In short, the kernel does expect to be able to call ck_epoch_call() and ck_epoch_poll_deferred() on records that are already in a read-side critical section.
In D17503#373574, @sbahra_repnop.org wrote:In D17503#373529, @jtl wrote:In D17503#373490, @sbahra_repnop.org wrote:See previous note in D17492 regarding the assumption that write-side functions are *not* called with-in a read-side critical. Does FreeBSD require that this is permitted?
See my comments in that review.
Regardless of whether that is true, it seems like this change would still be safe. Do you agree?
Is it expected by the kernel that ck_epoch write-side functions are safe to call on records that are already in a read-side critical section?
Helping me understand the intended use-case will allow me to answer accurately. There is further validation needed beyond poll.
Oct 7 2018
Oct 5 2018
As I pointed out on IRC, this problem is not specific to hwpmc. Nonetheless it does fix the issue here.
Is there a reason you didn't just update the diff on the existing review?
Oct 4 2018
- add #ifdef RACCT
- fix typo
Oct 3 2018
incorporate @alc feedback
@imp anyone else we should add as a reviewer?
incorporate feedback from @markj
I’ll update the patch with the other feedback.
@kib any further comments?
Oct 2 2018
In D17011#363656, @kib wrote:Can you add an explanation what exactly changes intend to fix, and how they achieve robustness improvements.
Fix patch
- use atop/ptoa macros
remove invalid assert
- remove unused force parameter
- no need to flush any more
- remove invalid assert
Sep 30 2018
Seems fine for now.
Sep 25 2018
pass properly scaled value to racct_add_force
incorporate feedback
fix KASSERT function names printed
fix KASSERTs and resourcevar.h comment
fix sense of new KASSERT