2010/2/26 Otto Moerbeek :
>> 2.
...
>> I think that we may introduce some variable - sysctl variable or
>> malloc.conf flag - which will prevent sys_mmap() or uvm_map_hint()
> If fragmentation really is a problem for you, my first reaction is:
> use a machine with a bigger adress spacce.
No deal.
> There are cases when we need memory rather than randomization.
> Dedicated database server is such case. Postgres can give more
> performance if it can use as much memory as userspace can allocate.
> Many big random holes quickly leads to fails of allocations. So then
> we must dramatically decre
On Fri, Feb 26, 2010 at 10:58:09AM +0500, Anton Maksimenkov wrote:
> 2010/2/20 Anton Maksimenkov :
> > it was started discussion about uvm_map.c improvements. I prepared the
> > diff and trying to explain it.
>
> In addition to that diff I want to discuss two problems.
>
> 1.
> AFAIK, the usersp
2010/2/20 Anton Maksimenkov :
> it was started discussion about uvm_map.c improvements. I prepared the
> diff and trying to explain it.
In addition to that diff I want to discuss two problems.
1.
AFAIK, the userspace malloc() uses mmap (sys_mmap) to do it's job. As
we can see, sys_mmap() uses uvm
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
[IMAGE]
Para visualizar este correo en el explorador, clic aqum
Este correo ha sido enviado a tech@openbsd.org | Remover suscripcisn
[IMAGE]
Episjeuhe_te tgm die}humsg http://www.e-shop.gr/newsletter/mail-100220.html
cia ma de_te tir pqosvoq]r lar
TGKEVYMIJES PAQACCEKIES 9:00-20:00 STO 211
5000500
Oi til]r isw}oum ap| 20/02/10 l]wqi 06/03/10, ]yr enamtk^seyr tym
apohel\tym jai l|mo cia ta l]kg tou e-shop.gr
Am h]kete ma diacqave_t
PoE!tovani,
Super ponude za mesec Ljubavi traju do kraja februara!
PodseDamo Vas da iskoristite ponudu za zaljubljene koja Vam je na
raspolaganju joE! samo 3 dana! Najbolje popuste na najpopularnije
proizvode moE>ete videti ako kliknete ovde!
Ne gubite vreme, prava je prilika da iznenadite onog
Seeing a thread on misc@ [1] earlier, I was wondering if the attached
patch would be an improvement to show a user where to look if they do
want a core dump from a setuid process. I changed the wording slightly
since my earlier posting.
Regards,
Rogier
References
1. MARC.info - 'Core dumps from
On 2010/02/25 00:18, Brian Keefer wrote:
> For the record, I've just patched -current with Brad's flow control diff from
> last year and now I'm getting 90Mbps with tcpbench on this card. I'm not sure
> if it was that diff or some other one in the last three years, but 800Kbps ->
> 90Mbps is quite
For the record, I've just patched -current with Brad's flow control diff from
last year and now I'm getting 90Mbps with tcpbench on this card. I'm not sure
if it was that diff or some other one in the last three years, but 800Kbps ->
90Mbps is quite a nice improvement.
Pity I didn't attach ifconf
10 matches
Mail list logo
