Hello.
I want to ask you about vmmap changes introduced here and in your
presentation http://openbsd.org/papers/tdose_memalloc/presentation.html
1. http://openbsd.org/papers/tdose_memalloc/presentation.html#%2816%29
"Browsers, java & mono breakage"
You pointed to some buggy software. If I underst
2011/4/19 Ariane van der Steldt :
> You now have feedback. People don't like your diff, told you why. You
> now have options:
> You didn't get negative feedback on the reserved entry. It works for
> your map, maybe it'll also work for the kernel_map? Most comments here
> are against the kentry map.
2011/4/19 Ariane van der Steldt :
> Your diff is reducable to:
> static struct vm_map_entry kentries[REALLY_BIG_NUMBER];
> And then managing that memory using vmmap.
Yes, more or less... But your example eats VA memory and physical
pages immediately and forever, while my diff tried to eat it on d
2011/4/18 Ted Unangst :
> +if (uvm.numof_free_kentries < 1) /*check to be safe*/
> +panic("uvm.numof_free_kentries[%d] < 1\n",
uvm.numof_free_kentries);
>>> This diff would take us back to the bad old days when running out of
entries led
>>> to a panic.
>> Totally conversely. As It was
2011/4/17 Ted Unangst :
>> This kentry_map must be used only for kentries allocation. Since all
> This really isn't that much different than the static entries we have
> now. You are pre-reserving them.
No. Now, we have to trust to kmthread to preallocate pages. It is not
possible to predict when
2011/4/5 Anton Maksimenkov :
> I have some idea related to allocator for (! __HAVE_PMAP_DIRECT) case.
...
> My idea is how to resolve that loop by another way.
> We must keep track the number of free kentries. And when we see, in
> uvm_mapent_alloc(), that there is only 1 kentry rem
2011/4/5 Artur Grabowski :
> - Use km_alloc for all backend allocations in pools.
> - Use km_alloc for the emergmency kentry allocations in uvm_mapent_alloc
> - Garbage collect uvm_km_getpage, uvm_km_getpage_pla and uvm_km_putpage
I have some idea related to allocator for (! __HAVE_PMAP_DIRECT)
2011/3/11 Anton Maksimenkov :
>> If some process can catch COM port in a way that noone can use the
>> port and noone can kill that process - it is wrong situation.
I think this would be a little bit better:
--- /usr/origsrc/sys/kern/tty.c Mon Oct 11 22:20:15 2010
+++ /usr/src/sy
Hi.
If someone has te vte (r6040 chip) network interface please, test this diff.
It solves problems like these:
> First, it seems that dhclient don't work on vte.
> Second, it seems vte looses network after minute(s) of inactivity
> (machine don't responds to ping etc).
> Network restores when I ty
2011/3/11 Anton Maksimenkov :
> If some process can catch COM port in a way that noone can use the
> port and noone can kill that process - it is wrong situation.
And here is the quick path which solves the problem:
--- /usr/origsrc/sys/kern/tty.c Mon Oct 11 22:20:15 2010
+++ /usr/src/sy
2011/3/11 Amit Kulkarni :
> I tried to do a similar thing, Ctrl + C on a fsck, kill -9 the fsck
> pid. But the process is not able to be killed. Finally found out that
> I/O stuff can't be killed in OpenBSD. Since you do I/O to COM port,
> and try to kill it... I don't know if its a bug though.
An
Hi.
It seems I catched some bug in kernel. I use some ugly program which
connects to COM-port and tries to do some activity.
You can see it's source here http://pastebin.com/kHLy26GD
I start it and try to kill it
# ./ct
writing bytes 36[ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 ff
Hi.
I found that manpage for imsg-family have a little mistake:
...
if (msgbuf_write(ibuf->w) < 0) {
...
It seems it should be:
if (msgbuf_write(&ibuf->w) < 0) {
--
antonvm
> I have SoC machine (dmesg below) which hangs on reboot in most cases.
It seems that the problem was resolved by just commenting "KBC_PULSE0"
related case in cpu_reset() and machine successfuly rebooted by
"triple fault and watchdog reset" bits (follow just after).
Should we think about sysctl to
Hello.
I have SoC machine (dmesg below) which hangs on reboot in most cases.
Serial console shows this:
login: /etc/rc.shutdown in progress...
stopping local daemons:.
Rsyncing disks... omplete.
then:
Rsyncing disks... doneete.
rebooting...
and then it hangs.
It hangs here almost 100% if serial c
2010/11/12 Stuart Henderson :
> In my case: system just appears to freeze, no response to numlock
> etc, cannot enter DDB (typing blind as I'm generally in X and
> the machine has no serial port, but no response to ctrl-alt-esc
> followed by boot r).
May be that problem
http://marc.info/?l=openbs
So, can I remind this simple cleanup?
2010/1/31 Anton Maksimenkov :
> Here is some cleanup of uvm_map.c code.
>
> At first, in uvm_map_advice() function.
> Let it looks as simple as uvm_map_inherit() - no need to lock/unlock map
> just to realize that sanity check fail. Also no n
Since I not found any support of that idea I think it is better to
keep things simple. So I introduce implementation of the "ReScan"
idea.
The diff must be almost the same as in the first message in thread. I
added some logic into uvm_map_findspace(). If it can't found
reasonable gap using hint it
2010/2/26 Anton Maksimenkov :
> The idea might be like this. We don't use uvm_map_hint(). In
> uvm_map_findspace() we get entry with biggest space. Then we generate
> random from range 0...MIN(space-length, 256M). Then we search first
> entry with space >= length+that_random.
2010/2/26 Anton Maksimenkov :
> *result = entry->start + that_random;
ur-r-r-gh *result = entry->end + that_random;
--
antonvm
2010/2/26 Anton Maksimenkov :
>> + ReScan:
It might be better solution. As I said to art@, we might generate
random exactly in uvm_map_findspace().
The idea might be like this. We don't use uvm_map_hint(). In
uvm_map_findspace() we get entry with biggest space. Then we generate
random
> + int try_rescan = 0;
Oh my mistake, sorry. It was so quick draft...
Of course try_rescan must be not 0 before the first scan:
try_rescan = 1;
> + ReScan:
> tmpsearch.space = length;
> tmp = RB_NFIND(uvm_tree_space, &map->rb_space, &tmpsearch);
> if (tmp == NULL)
be.
But what about this:
2010/2/26 Otto Moerbeek :
> On Fri, Feb 26, 2010 at 10:58:09AM +0500, Anton Maksimenkov wrote:
>> I think that if uvm_map_findspace() can't find space from "hint" then
>> it must retry searching _without_ hint (say, setting it to
>> ma
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.
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_
Hi.
In this thread http://marc.info/?l=openbsd-tech&m=126494185625212&w=2
it was started discussion about uvm_map.c improvements. I prepared the
diff and trying to explain it.
First, I introduce 2 trees here:
- uvm_tree_start, the RB_TREE indexed by entry's "start"
- uvm_tree_space, the RB_TREE
2010/2/8 Theo de Raadt :
> For those of you who asked why cp needs to be portable, come on.
> You've got it all wrong. If cp isn't written in a portable fashion,
> then what is the point of doing anything else in a portable fashion.
This is good and reasonable answer. So I think we should stop di
2010/2/7 Ted Unangst :
>> But using sysctl is insane. That is not portable.
> Why does cp need to be portable? Who's porting OpenBSD cp to other
systems?
Good question.
--
antonvm
2010/2/6 Jeff Ross :
> When I set shared_buffers to slightly less than 1/4 of my system ram I
> started this whole round of system panics and reports because in order to
> get postgres to start I then had to crank kern.shminfo.shmmax to 1GB, and
> that would trigger a panic very quickly under load.
2010/2/5 Anton Maksimenkov :
> set chared buffers to something not so big... say, 256Mb or so (I just
I misprint. Of course it's "shared", not "chared. Sorry.
--
antonvm
2010/2/5 Ted Unangst :
> On Thu, Feb 4, 2010 at 2:21 PM, Jeff Ross wrote:
>> kern.shminfo.shmall=512000
>> kern.shminfo.shmmax=76800
>
> Oh, when I said it was safe to crank shmmax I didn't know you'd be
> setting the bufcache to huge numbers too. ;)
Furthermore, postgres documentation recom
2010/2/3 Owain Ainsworth :
> ...you can't just go straight to the start of the map.
> Say i386 where W^X is done using segments. if you dump
> something right at the other end of the segment, that pretty much screws
> it. Perhaps going back to the min hint for the protection and trying to
> push ju
2010/2/3 Ariane van der Steldt :
> On Tue, Feb 02, 2010 at 01:21:55AM +0500, Anton Maksimenkov wrote:
>> uvm_map_lookup_entry()... in uvm_map_findspace()...
>
> I'm pretty sure that function is bugged: I think it doesn't do
> wrap-around on the search for an entry.
&
2010/2/2 Anton Maksimenkov :
> Overcomplicated using of RB_TREE in uvm_map_lookup_entry() making it
> hard to understand.
> I thinking about drop this RB_TREE out from uvm_map.c or completely
> rewrite using of this RB_TREE.
Oh, sorry, I mean "in uvm_map_findspace
2010/2/1 Bob Beck :
> On 31 January 2010 05:43, Anton Maksimenkov wrote:
>> Second, remove redundant "temp_entry" variable from both functions.
>> One "entry" variable is enough to do the job.
> I don't think you want to do that.. uvm_map_lookup_entry
Here is some cleanup of uvm_map.c code.
At first, in uvm_map_advice() function.
Let it looks as simple as uvm_map_inherit() - no need to lock/unlock map
just to realize that sanity check fail. Also no need to do it in every loop.
Second, remove redundant "temp_entry" variable from both functions.
2009/5/30 Henning Brauer :
> * Anton Maksimenkov [2009-05-30 07:58]:
>> In the last stage I want implement automatically creation of subqueues
>> by using some keyword for parent queue. For example:
> I don't think that is the right approach.
If so, isn't it ugly to
> Now I want to start from another side. I want make pfctl to create
> child queues automatically, using config like this:
> altq on $ext_if cbq bandwidth 100Mb queue { std, pq }
> queue std bandwidth 98Mb cbq(default, borrow)
> queue pq bandwidth 1024Kb cbq spray_child 4
Oh, I forgot the rule:
Ok, maybe I was far from current state of PF rules... Let's do step by step.
For start discussion I will use this more or less real example:
altq on $ext_if cbq bandwidth 100Mb queue { std, pq }
queue std bandwidth 98Mb cbq(default, borrow)
queue pq bandwidth 1024Kb cbq { pq_1, pq_2, pq_3, pq_4
>> I need some help with my idea about PF.
>> So, assume that we want to assign all packets passed that rule to one
>> of _subqueues_ of "pq" queue. Not to "pq" itself. That assignment must
>> be based on packet's destination IP address, so packets to 192.168.0.1
>> must be assigned to "pq_1" queue
I need some help with my idea about PF. I want to implement idea based
on freebsd's ipfw "mask dst-ip" feature.
Lets assume that we have some altq rules like this:
altq on $if cbq bandwidth 100Mb queue { std, ..., pq }
queue ...
queue pq bandwidth ... priority 1 cbq { pq_1, pq_2, pq_3,...}
41 matches
Mail list logo
