<feed xmlns='http://www.w3.org/2005/Atom'>
<title>wireguard-openbsd/sys/arch/amd64/include/vmparam.h, branch jd/queueboosts</title>
<subtitle>WireGuard implementation for the OpenBSD kernel</subtitle>
<id>https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/amd64/include/vmparam.h?h=jd%2Fqueueboosts</id>
<link rel='self' href='https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/amd64/include/vmparam.h?h=jd%2Fqueueboosts'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/'/>
<updated>2019-01-03T18:59:27Z</updated>
<entry>
<title>Crank MAXTSIZ to next pow2 (256MB) because a few piggy binaries</title>
<updated>2019-01-03T18:59:27Z</updated>
<author>
<name>deraadt</name>
<email>deraadt@openbsd.org</email>
</author>
<published>2019-01-03T18:59:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=aa12befff79dd77d7da03dda3a124b25c992c6d2'/>
<id>urn:sha1:aa12befff79dd77d7da03dda3a124b25c992c6d2</id>
<content type='text'>
compiled with retpoline enabled are even piggier now.
diagnosed with robert kettenis and drahn
</content>
</entry>
<entry>
<title>Hilarious!  We are not ready yet for large stack random biases, due to</title>
<updated>2015-02-08T03:48:25Z</updated>
<author>
<name>deraadt</name>
<email>deraadt@openbsd.org</email>
</author>
<published>2015-02-08T03:48:25Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=857f7c37ab02379e38c5b0668b3a06718a485dca'/>
<id>urn:sha1:857f7c37ab02379e38c5b0668b3a06718a485dca</id>
<content type='text'>
the stack region handling in uvm.
</content>
</entry>
<entry>
<title>Expand STACKGAP_RANDOM to 2MB on machines with large user VA</title>
<updated>2015-02-05T23:06:22Z</updated>
<author>
<name>deraadt</name>
<email>deraadt@openbsd.org</email>
</author>
<published>2015-02-05T23:06:22Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=63ea68d5cf7a1bcadd72528e574ae9d2764bbf27'/>
<id>urn:sha1:63ea68d5cf7a1bcadd72528e574ae9d2764bbf27</id>
<content type='text'>
ok kettenis
</content>
</entry>
<entry>
<title>Increase max data size. 32G is the new 640K.</title>
<updated>2014-03-26T19:39:39Z</updated>
<author>
<name>tedu</name>
<email>tedu@openbsd.org</email>
</author>
<published>2014-03-26T19:39:39Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=5f4c67d3331608122ef1cba133d325a9f7ec43be'/>
<id>urn:sha1:5f4c67d3331608122ef1cba133d325a9f7ec43be</id>
<content type='text'>
Using this much memory may have negative side effects, but at least now
you have the option. Here's some rope; have fun.
maybe ok a few people.
</content>
</entry>
<entry>
<title>Move declaration of struct vm_page_md from &lt;machine/vmparam.h&gt; to</title>
<updated>2014-01-30T18:16:41Z</updated>
<author>
<name>miod</name>
<email>miod@openbsd.org</email>
</author>
<published>2014-01-30T18:16:41Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=62fe2d4b3bff9db166916908a163621eefc781a0'/>
<id>urn:sha1:62fe2d4b3bff9db166916908a163621eefc781a0</id>
<content type='text'>
&lt;machine/pmap.h&gt; where it belongs, and compensate in &lt;uvm/uvm_extern.h&gt;
by including &lt;uvm/uvm_pmap.h&gt; before &lt;uvm/uvm_page.h&gt;. Tested on all
MACHINE_ARCH but amd64 and i386 (and hppa64).
</content>
</entry>
<entry>
<title>unifdef -D__HAVE_VM_PAGE_MD - no functional change.</title>
<updated>2014-01-23T22:06:29Z</updated>
<author>
<name>miod</name>
<email>miod@openbsd.org</email>
</author>
<published>2014-01-23T22:06:29Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=736608ca0c97261d341da497fbd8b423ad4a3a86'/>
<id>urn:sha1:736608ca0c97261d341da497fbd8b423ad4a3a86</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Bump MAXTSIZ to 128 MB, some binaries are quite large.</title>
<updated>2013-01-27T16:12:16Z</updated>
<author>
<name>fgsch</name>
<email>fgsch@openbsd.org</email>
</author>
<published>2013-01-27T16:12:16Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=9eca993d2c79c04c2425db2779ce9f075b56d3a1'/>
<id>urn:sha1:9eca993d2c79c04c2425db2779ce9f075b56d3a1</id>
<content type='text'>
Agreed with millert@ and guenther@
</content>
</entry>
<entry>
<title>Remove the freelist member from vm_physseg</title>
<updated>2011-05-30T22:25:20Z</updated>
<author>
<name>oga</name>
<email>oga@openbsd.org</email>
</author>
<published>2011-05-30T22:25:20Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=2ce3b4a8d453aa5b9e1d594f23fa8cfc79a224b6'/>
<id>urn:sha1:2ce3b4a8d453aa5b9e1d594f23fa8cfc79a224b6</id>
<content type='text'>
The new world order of pmemrange makes this data completely redundant
(being dealt with by the pmemrange constraints instead). Remove all code
that messes with the freelist.

While touching every caller of uvm_page_physload() anyway, add the flags
argument to all callers (all but one is 0 and that one already used
PHYSLOAD_DEVICE) and remove the macro magic to allow callers to continue
without it.

Should shrink the code a bit, as well.

matthew@ pointed out some mistakes i'd made.
``freelist death, I like. Ok.' ariane@
`I agree with the general direction, go ahead and i'll fix any fallout
shortly'' miod@ (68k 88k and vax i could not check would build)
</content>
</entry>
<entry>
<title>Normalize sentinel. Use _MACHINE_*_H_ and _&lt;ARCH&gt;_*_H_ properly and consitently.</title>
<updated>2011-03-23T16:54:33Z</updated>
<author>
<name>pirofti</name>
<email>pirofti@openbsd.org</email>
</author>
<published>2011-03-23T16:54:33Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=2fa72412907ae78c4787a4a8f888c5f0486e225c'/>
<id>urn:sha1:2fa72412907ae78c4787a4a8f888c5f0486e225c</id>
<content type='text'>
Discussed and okay drahn@. Okay deraadt@.
</content>
</entry>
<entry>
<title>oops, i forgot to check in the BRKSIZ define in uvm, but deraadt thinks</title>
<updated>2010-12-15T05:30:18Z</updated>
<author>
<name>tedu</name>
<email>tedu@openbsd.org</email>
</author>
<published>2010-12-15T05:30:18Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-openbsd/commit/?id=01d0831ff9fb70cc52362307e6c82e7468478c72'/>
<id>urn:sha1:01d0831ff9fb70cc52362307e6c82e7468478c72</id>
<content type='text'>
its better as a per arch MD define anyway.  all default to MAXDSIZ as before.
</content>
</entry>
</feed>
