{"push_id":2450858889,"size":8,"distinct_size":8,"ref":"refs/heads/master","head":"ce55b46f2862cfd26084edd000102cb929d092d2","before":"60d1e1d5928e91ddd2e068f037314981719b8a0d","commits":[{"sha":"b8ac450ecca3ee71bb760d971bfc93ee3c9c18ea","author":{"name":"glebius","email":"80e534fe7e1b330136d3a302de2261cd031ee58f@FreeBSD.org"},"message":"Handle a special case when a slab can fit only one allocation,\nand zone has a large alignment. With alignment taken into\naccount uk_rsize will be greater than space in a slab. However,\nsince we have only one item per slab, it is always naturally\naligned.\n\nCode that will panic before this change with 4k page:\n\n\tz = uma_zcreate(\"test\", 3984, NULL, NULL, NULL, NULL, 31, 0);\n\tuma_zalloc(z, M_WAITOK);\n\nA practical scenario to hit the panic is a machine with 56 CPUs\nand 2 NUMA domains, which yields in zone size of 3984.\n\nPR:\t\t227116\nMFC after:\t2 weeks","distinct":true,"url":"https://api.github.com/repos/bsd-hacker/freebsd/commits/b8ac450ecca3ee71bb760d971bfc93ee3c9c18ea"},{"sha":"f1818db2fc5cb8693a2d7d16f3c6725f8dba3601","author":{"name":"glebius","email":"80e534fe7e1b330136d3a302de2261cd031ee58f@FreeBSD.org"},"message":"In uma_startup_count() handle special case when zone will fit into\nsingle slab, but with alignment adjustment it won't. Again, when\nthere is only one item in a slab alignment can be ignored. See\nprevious revision of this file for more info.\n\nPR:\t\t227116","distinct":true,"url":"https://api.github.com/repos/bsd-hacker/freebsd/commits/f1818db2fc5cb8693a2d7d16f3c6725f8dba3601"},{"sha":"a76113efee2d017e574de473e547e8210dbc6736","author":{"name":"glebius","email":"80e534fe7e1b330136d3a302de2261cd031ee58f@FreeBSD.org"},"message":"Use UMA_SLAB_SPACE macro. No functional change here.","distinct":true,"url":"https://api.github.com/repos/bsd-hacker/freebsd/commits/a76113efee2d017e574de473e547e8210dbc6736"},{"sha":"a9c1c585d1ce95eb862bcd2717d9a705a3a2e867","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@FreeBSD.org"},"message":"x86 cpu_reset_proxy: no need to stop_cpus() the original processor\n\nThe processor is \"parked\" in a spin-loop already and that's sufficient\nfor the reset.  There is nothing that stop_cpus() would add here, only\nextra complexity and fragility.\nThe original processor does not need to enable interrupts now, in fact,\nit must not do that.\n\nMFC after:\t2 weeks","distinct":true,"url":"https://api.github.com/repos/bsd-hacker/freebsd/commits/a9c1c585d1ce95eb862bcd2717d9a705a3a2e867"},{"sha":"f90974138977a707fae417e7c1d7f023bb0053df","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@FreeBSD.org"},"message":"x86 cpu_reset: if failed to switch to BSP proceed to cpu_reset_real\n\nIf cpu_reset() is called on an AP and if it somehow fails to wake the\nBSP, then it's better to attempt the reset on the AP than just sit there\nspinning on an unusable and undebuggable system.\n\nMFC after:\t16 days","distinct":true,"url":"https://api.github.com/repos/bsd-hacker/freebsd/commits/f90974138977a707fae417e7c1d7f023bb0053df"},{"sha":"5fa8a3511e07d89c67bfae4f03d8ebd25178897c","author":{"name":"andrew","email":"6b7c097d961f68685fc978cf91eeae17be6cbb45@FreeBSD.org"},"message":"Add the missing header for malloc(9). It was pulled in through header\npollution that doesn't seem to exist in some configurations.","distinct":true,"url":"https://api.github.com/repos/bsd-hacker/freebsd/commits/5fa8a3511e07d89c67bfae4f03d8ebd25178897c"},{"sha":"cbde65132db670762f699bd6f0a70504f6f6e603","author":{"name":"avg","email":"b24d11afb16644e3ff52469bebd6e863d3282d4e@FreeBSD.org"},"message":"unify amd64 and i386 cpu_reset() in x86/cpu_machdep.c\n\nBecause I didn't see any reason not too.\nI've been making some changes to the code and couldn't help but notice\nthat the i386 and am64 code was nearly identical.\n\nMFC after:\t17 days","distinct":true,"url":"https://api.github.com/repos/bsd-hacker/freebsd/commits/cbde65132db670762f699bd6f0a70504f6f6e603"},{"sha":"ce55b46f2862cfd26084edd000102cb929d092d2","author":{"name":"markj","email":"47b3ed30e5a83fd756a28e99bf1950376aed42e8@FreeBSD.org"},"message":"Ensure the background laundering threshold is positive after a scan.\n\nThe division added in r331732 meant that we wouldn't attempt a\nbackground laundering until at least v_free_target - v_free_min clean\npages had been freed by the page daemon since the last laundering. If\nthe inactive queue is depleted but not completely empty (e.g., because\nit contains busy pages), it can thus take a long time to meet this\nthreshold. Restore the pre-r331732 behaviour of using a non-zero\nbackground laundering threshold if at least one inactive queue scan has\nelapsed since the last attempt at background laundering.\n\nSubmitted by:\ttijl (original version)","distinct":true,"url":"https://api.github.com/repos/bsd-hacker/freebsd/commits/ce55b46f2862cfd26084edd000102cb929d092d2"}]}
{"actor":{"display_login":"bsd-hacker"}}