| Pointer Email Marketing |
| Feb 3, 5:47 pm 2010 |
| Mike Belopuhov | remove a libcrypto dependancy in mount_vnd(8)
hey,
while looking thru bioctl stuff, i've accidentaly stumbled upon
pbkdf2 thing and found out that mount_vnd still uses local
pkcs5_pbkdf2.c from NetBSD and links against libcrypto (although
it's a static binary). reduction in size is about 2.5 times
(from 353K to 145K), so it's a win, right? :)
i've tested compatibility between old and new versions and
everything looks.. er.. compatible.
so sending this out that it won't be lost.
Index: ...
| Feb 4, 9:25 am 2010 |
| Brock suit |
| Feb 4, 8:51 am 2010 |
| members | e-shop.gr: Εκπτώσεις α
Episjeuhe_te tgm die}humsg http://www.e-shop.gr/newsletter/mail-100122.html
cia ma de_te tir pqosvoq]r lar
TGKEVYMIJES PAQACCEKIES 9:00-20:00 STO 211
5000500
Oi til]r isw}oum ap| 24/01/10 l]wqi 10/02/10, ]yr enamtk^seyr tym
apohel\tym jai l|mo cia ta l]kg tou e-shop.gr
Am h]kete ma diacqave_te ap| tg
k_sta emgl]qysgr tou e-shop.gr, paqajako}le apamt^ste sto paq|m le
t_tko(subject) tou lgm}lat|r sar: DIACQAVG.
| Feb 3, 6:38 pm 2010 |
| Atte | Re: xargs -0 and -L
You seem to have misinterpreted the purpose of -print0 and -0. From
Linux find(1):
-print0
True; print the full file name on the standard output, followed
by a null character (instead of the newline character that -print uses).
This allows file names that contain newlines or other types of white
space to be correctly interpreted by programs that process the find
output. This option corresponds to the -0 option of xargs.
Using -0 for xargs simply means "Use \0 as otherwise \n or ...
| Feb 4, 3:48 am 2010 |
| Philip Guenther | Re: xargs -0 and -L
We understand the purpose of -0. Are you sure you understand the
difference between -n and -L? AFAICT, the behavior you desire can be
obtained portably and without requiring an alteration to the
definition of 'line' using -0 -n # -x
Philip Guenther
| Feb 4, 10:59 am 2010 |
| Anton Maksimenkov | Re: some cleanup of of uvm_map.c
Let me introduce my idea.
In fact, we have only two functions in uvm_map.c which make searching
in maps. These are uvm_map_lookup_entry() and uvm_map_findspace().
The uvm_map_lookup_entry() do search by address (VA), while
uvm_map_findspace() do search by free space.
And we have a RB_HEAD(uvm_tree, vm_map_entry) rbhead, which is
"indexed by address" (see uvm_compare()). Since that this RB_TREE
provide a "searching by address" option to us. This is what the
RB_TREE used for.
But when ...
| Feb 3, 11:51 pm 2010 |
| Anton Maksimenkov | Re: some cleanup of of uvm_map.c
I remember about MAP_FIXED, just not mentioned it in my not-so-short message ;)
And I don't want 2 vm_map_entry per allocation, I only need to keep
each vm_map_entry in both trees. One vm_map_entry can contain 2
separate RB_TREE entries (for both trees), so each tree can work with
that vm_map_entry independantly.
Can anyone explain me what is the problem with i386 segments? Or
better supply some links to docs which explain it.
I don't understand what you mean - MAP_FIXED flag is the problem ...
| Feb 4, 10:57 am 2010 |
| Ariane van der Steldt | Re: some cleanup of of uvm_map.c
uvm_map_findspace() is also used when searching by addr:
mmap(..., MAP_FIXED) requires a search by addr.
uvm_map_findspace() should also be able to take an addr constraint: like
Nah, RB_AUGMENT is easy. When an item in the tree is deleted, each node
in the tree that is altered (position or insertion/removal) has each of
its children and each of its parents RB_AUGMENTed. The RB_AUGMENT calls
are done in such a way that each node is process prior to
I use that trick in uvm_pmemrange. It's a ...
| Feb 4, 6:50 am 2010 |
| Ariane van der Steldt | Re: some cleanup of of uvm_map.c
Oh, I didn't explain clearly what I meant there.
Suppose you have a 4MB entry with free memory.
You need to allocate, say, 4kB. This would split the entry in:
[1] free range in front of allocation
[2] allocated range
[3] free range behind allocation
The idea is that one part of the memory is executable, the other half is
not. We like the executable code of a process to be mapped in the
executable half, while we want data to not be in that part.
Paper by Theo has a good explanation on ...
| Feb 4, 11:54 am 2010 |
| Ariane van der Steldt | Re: UBC?
Maybe the shm maps shared between all the postgres processes causes
trouble. What's the number of connections you allow the server to have?
What amount of shm does postgres use?
The amount of memory * the number of postgres entries is the number of
pv-entries required to keep them up. Each pv-entry is 16 byte
(4 pointers of 4 byte each). This value probably overflows the
kmem_map.
What's the value of sysctl vm.nkmempages?
Adapting any of these values should cause you to no longer hit ...
| Feb 4, 11:36 am 2010 |
| Jeff Ross | Re: UBC?
In sysctl I have this:
kern.shminfo.shmall=512000
kern.shminfo.shmmax=768000000
I'm only allowing 100 connections to Postgresql, however, these panics are
That is what I've been trying to do. This is (someday) destined to be a web
server driving postgresql backed drupal web sites. The postgresql guidelines
for performance don't seem to apply to OpenBSD, for example, they tell you to
set the shared_buffers in postgresql.conf to 1/4 of the available memory in
the server. I tried ...
| Feb 4, 12:21 pm 2010 |
| Jeff Ross | Re: UBC?
Okay, I've been testing. I brought everything up to current, applied the
ami.c patch sent by David Gwynne as modified by Phillip Guenther, and the
patch to bus_dma.c sent by Kenneth Westerback.
I started by setting kern.bufcachepercent=60 and then moving down by 10 after
each panic. Anything 20 or greater triggers the same panic as above.
I then set it to 10 to see what would happen. The load ran okay, but I did
get three uvm_mapent_alloc: out of static map entries entries into the ...
| Feb 4, 9:29 am 2010 |
| Ted Unangst | Re: UBC?
Oh, when I said it was safe to crank shmmax I didn't know you'd be
As I pointed out in that thread, the 1GB limit does not apply to shared
Even so, I'm not sure how you're interpreting these numbers. shmmax
is total across all processes, not process. Your statement seems to
imply a shm setting that's per postmaster, based on dividing total RAM
between them, which would also leave no memory free for your 90%
buffer cache.
The long and short of the problem is that you have a certain ...
| Feb 4, 1:40 pm 2010 |
