On 17/02/14 10:11, Kieran Devlin wrote:
the original implementation use identical logic for both ‘high’ ‘low’,
which will cause ‘high’ ‘low’ end up at same RB-tree node, instead of an
expected interval.
and finally, break ‘for’ loop logic
luckily all these conditions never meet in practice.
On 11/09/12 08:56, Gerhard Roth wrote:
On Thu, 08 Nov 2012 16:22:41 -0500
Ted Unangst t...@tedunangst.com wrote:
On Thu, Nov 08, 2012 at 13:34, Ilya Bakulin wrote:
The problem seems to be in uvm_map_pageable_all() function
(sys/uvm/uvm_map.c). This function is a special case of
Hi,
This diff implements yielding in the vm system, with the intention to
make expensive system calls preempt every once in a while, to allow
userland system calls to progress.
It's a very conservative application at the moment, only interleaving
during memory unmapping. If this works, we can
Hi,
The reaper is not very nice: it blocks any access to the kernel (i.e.
syscalls) until it is done with its work. For big processes, this may
result in stalls in userspace. This diff attempts to relieve it by
yielding the reaper during this operation.
Please test this diff
Hi,
With the recent introduction of vmmap, I introduced a slowdown which
affects programs with alot of memory (browsers for instance). First of
all, since I've heard very few complaints, thanks for putting up with
this.
The reason for this e-mail is, that I have a diff. This diff should
make
Hi,
Just to prove my point that vmmap testing is still relevant: today a bug
got found and fixed, where grepping a 1.7GB file on i386 tripped an
assertion (I love assertions).
This brings the latest versions to:
http://www.stack.nl/~ariane/vmmap_sys.diff.65
(apply against /usr/src/sys)
On Wed, Jan 18, 2012 at 04:41:35PM +0100, Gregor Best wrote:
after a long time of silence here's a second iteration of the patch.
I've addressed a few concerns voiced here:
* Process lookup and friends now have O(log n) runtime. I achieved that
by abusing RB-trees as priority queues since
On Sat, Jan 07, 2012 at 11:47:32PM +0100, Juan Francisco Cantero Hurtado wrote:
On Fri, 06 Jan 2012 23:51:28 +0100, Ariane van der Steldt
ari...@stack.nl wrote:
I found and fixed the i386 bug. Please test this, to confirm that it
fixes the problem (and doesn't introduce anything else
On Sun, Jan 08, 2012 at 01:05:27PM +, Miod Vallat wrote:
Posix says that mmap(2)ing 0 bytes is bad and furthermore, our subsystem
is not written to support this (because there is no difference between
no allocation and a 0-byte allocation).
Strictly speaking, mmap(2) is to return
On Sat, Jan 07, 2012 at 11:30:59AM +, Stuart Henderson wrote:
Can anyone suggest reasons for a firewall doing this? Happened a few
times to this machine, first on i386 GENERIC from May 3, now on Dec 9th.
panic: pmap_remove_ptes: unmanaged page marked PG_PVLIST, va = 0x56c5000, pa
=
Hi,
Posix says that mmap(2)ing 0 bytes is bad and furthermore, our subsystem
is not written to support this (because there is no difference between
no allocation and a 0-byte allocation).
Strictly speaking, mmap(2) is to return EINVAL for 0 byte allocations
and I intend to get that into the
Hi,
I found and fixed the i386 bug. Please test this, to confirm that it
fixes the problem (and doesn't introduce anything else, ofcourse).
(vmmap_sys relative to /usr/src/sys, vmmap_userland relative to /usr/src)
New version of the diff:
http://www.stack.nl/~ariane/vmmap_sys.diff.64
with
On Sat, Dec 31, 2011 at 11:49:13PM -0500, Geoff wrote:
These patches are submitted for your amusement.
Nice catch below (but why hide a good bugfix in so many lines?) :)
Index: uvm/uvm_pmemrange.c
===
RCS file:
On Sat, Dec 31, 2011 at 11:24:54AM +0100, Alexander Schrijver wrote:
On Fri, Dec 30, 2011 at 05:55:27PM +0100, Ariane van der Steldt wrote:
I'll need testing on any and all architectures.
Is this in snapshots too?
No, it's not in snapshots.
--
Ariane
On Fri, Dec 30, 2011 at 02:42:18PM +0100, Ariane van der Steldt wrote:
The huge diff included below is to replace vmmap for something that
works a lot better. This is the second version I plan to commit.
I have been running this on my laptop for months and have had no
problems.
The current
On Fri, Dec 30, 2011 at 03:04:30PM +0100, Ariane van der Steldt wrote:
On Fri, Dec 30, 2011 at 02:42:18PM +0100, Ariane van der Steldt wrote:
The huge diff included below is to replace vmmap for something that
works a lot better. This is the second version I plan to commit.
I have been
+ * Copyright 2011 Ariane van der Steldt ari...@openbsd.org
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above
On Tue, Sep 20, 2011 at 09:47:45AM +0200, Mark Kettenis wrote:
Date: Tue, 20 Sep 2011 01:41:35 +0300
From: Paul Irofti p...@irofti.net
Linux keeps surprising me everytime!
This time its their pipe2 system call which adds flags to the pipe call.
Its the unix-ish way apparently to
On Sun, Sep 18, 2011 at 10:27:37PM +0200, Michael Knudsen wrote:
Does this make sense?
Since it's been taken off the list, the splusb is indeed no longer
required. Either way is fine with me though, I doubt the zeroing will
take that many cycles to really matter.
Index: ehci.c
On Tue, Jul 12, 2011 at 02:10:07PM -0700, Matthew Dempsky wrote:
ok?
ok ariane@
Index: catopen.c
===
RCS file: /home/mdempsky/anoncvs/cvs/src/lib/libc/nls/catopen.c,v
retrieving revision 1.13
diff -U5 -p -r1.13 catopen.c
---
On Tue, Jul 12, 2011 at 08:37:16PM +0200, Otto Moerbeek wrote:
On Tue, Jul 12, 2011 at 08:24:34PM +0200, Ariane van der Steldt wrote:
On Tue, Jul 12, 2011 at 01:23:52PM +0200, Otto Moerbeek wrote:
at the cost of some speed, reduce the malloc cache size to 0 with
flag 'S'. This means
On Thu, Jun 23, 2011 at 07:04:48PM +0100, Owain Ainsworth wrote:
How about this now?
On Tue, May 31, 2011 at 12:05:04AM +0100, Owain Ainsworth wrote:
These functions used to be big and complicated, now they are glorified
wrappers around pmemrange and don't really need their own file.
On Thu, Jun 23, 2011 at 07:04:39PM +0100, Owain Ainsworth wrote:
How about this now?
On Tue, May 31, 2011 at 12:03:49AM +0100, Owain Ainsworth wrote:
It will handle an empty list just fine (there is a potential small
optimisation in there to avoid grabbing the fpageqlock if no pages need
On Thu, Jun 23, 2011 at 07:04:57PM +0100, Owain Ainsworth wrote:
How about this now?
On Tue, May 31, 2011 at 12:06:15AM +0100, Owain Ainsworth wrote:
ok?
Ok.
diff --git uvm/uvm_fault.c uvm/uvm_fault.c
index 76f0708..76429dc 100644
--- uvm/uvm_fault.c
+++ uvm/uvm_fault.c
@@
On Thu, Jun 23, 2011 at 07:05:25PM +0100, Owain Ainsworth wrote:
How about this now?
I've got some more important uvm diffs on the way I but would like to
get the small ones out of my tree.
ok.
On Tue, May 31, 2011 at 12:09:35AM +0100, Owain Ainsworth wrote:
No functional change since
On Tue, Jun 21, 2011 at 09:00:49PM +0200, Ariane van der Steldt wrote:
Bus_dmamem_map has a bug in its error path, where it frees the wrong
memory in the wrong way.
After some discussion on icb, the comments and the pmap_remove can go
too. The pmap_remove is executed by uvm_km_free
Hi,
Bus_dmamem_map has a bug in its error path, where it frees the wrong
memory in the wrong way. Take this code in sparc64 for example:
va = uvm_km_valloc(kernel_map, size);
...
TAILQ_FOREACH(m, mlist, pageq) {
#ifdef DIAGNOSTIC
if (size == 0)
On Tue, Jun 07, 2011 at 06:51:31PM +0200, Christian Ehrhardt wrote:
while reading through uvm code I stubled accross a piece of code that
appears to be buggy. Here's the proposed patch, rational follows:
Index: uvm_vnode.c
===
On Tue, Jun 07, 2011 at 11:01:53PM +0100, Owain Ainsworth wrote:
On Tue, Jun 07, 2011 at 06:51:31PM +0200, Christian Ehrhardt wrote:
Hi,
while reading through uvm code I stubled accross a piece of code that
appears to be buggy. Here's the proposed patch, rational follows:
Index:
On Fri, May 20, 2011 at 11:23:47AM +0200, Mike Belopuhov wrote:
On Fri, May 20, 2011 at 4:04 AM, Ariane van der Steldt ari...@stack.nl
wrote:
AVL trees have a difference of max 1 between the longest and shortest
path to a leaf, whereas RB-trees have at max the longest path be double
On Thu, May 19, 2011 at 12:13:37PM +0200, Mark Kettenis wrote:
Date: Thu, 19 May 2011 03:32:10 +0200
From: Ariane van der Steldt ari...@stack.nl
I would respond in-thread, but I can't find the thread that had the
original report that emacs-22 doesn't work under vmmap. Perhaps
On Thu, May 19, 2011 at 07:33:22PM +0200, Mike Belopuhov wrote:
On Thu, May 19, 2011 at 7:25 PM, Michael Pounov mi...@aitbg.com wrote:
Not see differences in results with performance from RB tree vs AVL,
Which tree size did you use to test that? Which insert order (yes, this
is relevant: with
Hi,
It turns out that on sparc64, doing something like
show map /f *kernel_map
in ddb, makes you crash with a nullpointer exception.
Diff below makes sure we read all bytes of the pointer. The int in the
original code also explains why amd64 (little-endian arch) never had a
problem.
To test
Hi,
I would respond in-thread, but I can't find the thread that had the
original report that emacs-22 doesn't work under vmmap. Perhaps it was
only on icb...
Anyways, emacs-22.3p8 doesn't work under vmmap on i386. And the lovely
thing is, it's not my bug. :)
Emacs, by way of elf commands,
On Thu, May 19, 2011 at 03:32:10AM +0200, Ariane van der Steldt wrote:
Hi,
I would respond in-thread, but I can't find the thread that had the
original report that emacs-22 doesn't work under vmmap. Perhaps it was
only on icb...
Anyways, emacs-22.3p8 doesn't work under vmmap on i386
On Sat, Apr 16, 2011 at 11:52:34AM -0400, Brad wrote:
On 08/04/11 6:27 PM, Brad wrote:
On Thu, Apr 07, 2011 at 09:00:45PM -0400, Brad wrote:
Some _LP64 ifdef's leftover from rev 1.1. They appear to be unnecessary
since this code is only for amd64 anyway and thus a 64-bit arch.
Index:
On Fri, May 13, 2011 at 11:36:48PM +0100, Owain Ainsworth wrote:
On Mon, May 09, 2011 at 10:15:23PM +0100, Owain Ainsworth wrote:
On Mon, May 09, 2011 at 07:22:01PM +0100, Owain Ainsworth wrote:
The new world order of pmemrange makes this data completely redundant
(being dealt with by the
On Wed, May 11, 2011 at 03:44:45AM +0200, Ariane van der Steldt wrote:
On Wed, May 11, 2011 at 03:43:19AM +0200, Ariane van der Steldt wrote:
The newest version of vmmap (as of now) is vmmap_sys.diff.26
Since the diff is scheduled to go in may 20 and has a lot of changes and
fixes, please
On Wed, May 11, 2011 at 03:43:19AM +0200, Ariane van der Steldt wrote:
The newest version of vmmap (as of now) is vmmap_sys.diff.26
Since the diff is scheduled to go in may 20 and has a lot of changes and
fixes, please test this diff and report any failures and successes.
I use this separate e
Hi,
du.c doesn't define its tree prototypes. However, if I understand man tree,
it should.
Ok?
--
Ariane
Index: du.c
===
RCS file: /cvs/src/usr.bin/du/du.c,v
retrieving revision 1.23
diff -u -d -p -r1.23 du.c
--- du.c27
Hi,
If I'm being nice and you appreciate that and really feel you have to
tell me, fine. I like compliments. However don't use your compliment to
trash talk another developer.
I you don't like the behaviour of someone, you can tell them directly
or you can pkg_add procmail. Your attack made your
Hi,
MMU address space holes are at a fixed position (ofcourse).
This diff makes sure the FIXED position flag is specified when mapping
them in and complains loudly otherwise.
While there, check some other flag mistakes (which don't happen in the
kernel).
This diff prepares for the vmmap
On Tue, Apr 19, 2011 at 11:26:16AM +0600, Anton Maksimenkov wrote:
2011/4/19 Ariane van der Steldt ari...@stack.nl:
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
On Tue, Apr 19, 2011 at 09:49:43AM -0600, Artur Grabowski wrote:
Free the correct memory when we failed to allocate va.
ok ariane@
Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.97
diff -u
On Tue, Apr 19, 2011 at 11:01:54AM -0700, Matthew Dempsky wrote:
pmap(9) says pmap_update() 'must' be called after pmap_kenter_pa()...
ok?
Ok ariane@
Index: uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving
On Mon, Apr 18, 2011 at 10:24:32AM +0600, Anton Maksimenkov wrote:
2011/4/18 Ted Unangst ted.unan...@gmail.com:
+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
On Wed, Apr 06, 2011 at 10:31:14AM +0200, Mark Kettenis wrote:
Date: Tue, 5 Apr 2011 18:42:47 +0200
From: Ariane van der Steldt ari...@stack.nl
So it turns out that my allocator is not capable of handling the pmap_prefer
horror. This diff exports the actual parameters of pmap_prefer, so I
Hi,
So it turns out that my allocator is not capable of handling the pmap_prefer
horror. This diff exports the actual parameters of pmap_prefer, so I can
make the allocator deal with this intelligently.
I need compile tests on:
- arm
- hppa
- hppa64
- m68k
- mips64
- sh
- sparc
- sparc64
Since
On Wed, Apr 06, 2011 at 12:12:35AM +0600, Anton Maksimenkov wrote:
2011/4/5 Anton Maksimenkov anton...@gmail.com:
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.
Hi,
Test the iterated range, instead of the range chosen to not meet the
assert. This has been broken for a long time, but apparently no-one hit
it so far.
While here, change the KASSERT to a KDASSERT, as it is a validation of
internal state of pmemrange.
Ok?
--
Ariane
Index: uvm_pmemrange.c
On Mon, Apr 04, 2011 at 03:00:43PM +0200, Ariane van der Steldt wrote:
Please test this diff to uvm_map on as many architectures as possible.
Contains a number of fixes and a better algorithm.
It makes sure random address space allocations happen (and enables it in
the kernel) without causing
On Mon, Apr 04, 2011 at 03:54:32PM -0600, Artur Grabowski wrote:
First proper use of the new km_alloc.
- Change pool constraints to use kmem_pa_mode instead of uvm_constraint_range
- Use km_alloc for all backend allocations in pools.
- Use km_alloc for the emergmency kentry allocations in
Hi,
This function yields the number of avail pages (pages that exist and are
not mapped to kernels or pre-uvm data) in a given address range.
Beck needs this.
Ok?
--
Ariane
Index: uvm/uvm_page.c
===
RCS file:
On Tue, Mar 01, 2011 at 05:37:49PM -0600, Amit Kulkarni wrote:
I found 2 possible null pointers by clang static analyzer and I have
attached it to email later. I was also reading the code in this file
and I found out that
1) most of the time in uvm_pmr_getpages(), a newly inserted printf at
On Fri, Dec 24, 2010 at 05:14:13PM -0500, Ted Unangst wrote:
On Fri, Dec 24, 2010 at 5:02 PM, Mark Kettenis mark.kette...@xs4all.nl
wrote:
Date: Fri, 24 Dec 2010 16:54:23 -0500 (EST)
From: Ted Unangst ted.unan...@gmail.com
increase the hard limit on i386 max data size to 2GB-1. This
On Fri, Dec 10, 2010 at 02:04:17PM +0100, Wouter Coene wrote:
According to Ariane van der Steldt (ari...@stack.nl):
On Thu, Dec 09, 2010 at 10:32:57PM +0100, Wouter Coene wrote:
+ addr = uvm_km_kmemalloc(kernel_map, NULL, PAGE_SIZE,
+ UVM_KMF_CANFAIL
On Thu, Dec 09, 2010 at 10:32:57PM +0100, Wouter Coene wrote:
On 9 dec 2010, at 08:32, Ariane van der Steldt wrote:
I'm not yet convinced. What are you trying to do?
Pretty much as I described: I allocate kernel memory through
uvm_km_kmemalloc() from kernel_map, and then free it through
On Wed, Dec 08, 2010 at 04:49:16PM +0100, Wouter Coene wrote:
Having spent quite some hours figuring out why the kernel panics when I free
memory allocated through uvm_km_kmemalloc() with uvm_km_free()
(pmap_remove_pte: managed page without PG_PVLIST for address on amd64),
I added the
On Wed, Nov 03, 2010 at 02:33:12PM +0200, Alexey Suslikov wrote:
This is somewhat ports related, but I decided to ask here before going
further with diff.
Well, we have Asterisk 1.6.2.14-rc1 going segfault:
#0 generic_http_callback (format=FORMAT_XML, remote_address=0x4001,
On Fri, Feb 05, 2010 at 04:03:33PM -0700, Jeff Ross wrote:
Could I avoid all of this messing around if I had a server that could run
amd64? How would a dual processor 1.8 Opteron 244 w/4GB ram compare to this
2.4GHZ dual XEON w/4GB ram? Bog knows I don't need another server, but...
amd64
On Thu, Feb 04, 2010 at 11:51:11AM +0500, Anton Maksimenkov wrote:
2010/2/3 Ariane van der Steldt ari...@stack.nl:
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
On Thu, Feb 04, 2010 at 09:29:13AM -0700, Jeff Ross wrote:
Jeff Ross wrote:
On Sat, 30 Jan 2010, Bob Beck wrote:
Ooooh. nice one. Obviously ami couldn't get memory mappings and
freaked out.
While not completely necessary, I'd love for you to file that whole
thing into sendbug()
On Sun, Jan 31, 2010 at 05:43:02PM +0500, Anton Maksimenkov wrote:
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
On Tue, Feb 02, 2010 at 01:21:55AM +0500, Anton Maksimenkov wrote:
2010/2/2 Anton Maksimenkov anton...@gmail.com:
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
On Mon, Feb 01, 2010 at 11:30:06PM -0500, Ted Unangst wrote:
I think this fixes the problem with sleeping and holding pseg_lck.
Index: uvm_extern.h
===
RCS file: /home/tedu/cvs/src/sys/uvm/uvm_extern.h,v
retrieving revision
On Sun, Jan 31, 2010 at 12:15:58PM -0701, Jeff Ross wrote:
On Sat, 30 Jan 2010, Bob Beck wrote:
Ooooh. nice one. Obviously ami couldn't get memory mappings and freaked
out.
While not completely necessary, I'd love for you to file that whole
thing into sendbug() in a pr so we don't
On Thu, Jan 28, 2010 at 06:55:55PM +0300, Mike Belopuhov wrote:
could someone please enlighten me how this uvm_pseg_get is supposed
to work?
uvm_pseg_get
mtx_enter(uvm_pseg_lck);
`- uvm_pseg_init
`- uvm_km_valloc
`- uvm_km_valloc_align
`- uvm_map
67 matches
Mail list logo
