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 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 uvm_map_pageable",
which tries to
On Mon, Jun 25, 2012 at 12:09:33AM +0300, dsp wrote:
> We observe the following behaviour when running nc -ul.
> The server begins on a recvfrom() and when data arrives it
> connects() the socket.
> When the client dies , the server remains in a connected state
> therefore ignoring subsequent data
On Thu, Jun 14, 2012 at 10:01:33PM +, Ted Unangst wrote:
> .
> >
> >> If neither is true, we don't preempt (thus not calling mpswitch(), not
> >> releasing the kernel lock etc etc). For this reason it doesn't work
> >> well on SMP. Unfortunately the above conditions may be false if for ex
>
On Thu, Jun 14, 2012 at 12:19:24PM +0200, Mark Kettenis wrote:
> > Date: Thu, 14 Jun 2012 08:58:25 +0200
> > From: Alexandre Ratchov
> >
> > On Thu, Jun 14, 2012 at 03:48:12AM +0200, Ariane van der Steldt wrote:
> > > Hi,
> > >
> > > This
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 st
On Mon, Apr 16, 2012 at 12:34:28AM +0200, Juan Francisco Cantero Hurtado wrote:
> On Sun, Apr 15, 2012 at 07:30:21PM +0200, Ariane van der Steldt wrote:
> > 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
Hi,
This diff is called 'vmmap_reaperyield.diff.1_flags_only'. It's the
proper way forward for the reaperyield diff I mailed earlier.
This largely mechanical diff adds flags to uvm_unmap, uvmspace_free and
related functions. The diff should have no functional change. I need
this to make uvm_un
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 (vmmap_reaperyield.
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 th
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)
http://w
On Fri, Feb 17, 2012 at 10:01:49PM +0600, Anton Maksimenkov wrote:
> 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, j
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 si
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
> wrote:
> > I found and fixed the i386 bug. Please test this, to confirm that it
> > fixes the problem (and doesn't introduce
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 retur
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 kernel
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
> = 0x
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 corre
On Thu, Jan 05, 2012 at 07:57:55PM +0100, Juan Francisco Cantero Hurtado wrote:
> On Fri, 30 Dec 2011 17:55:27 +0100, Ariane van der Steldt
> wrote:
>
> > On Fri, Dec 30, 2011 at 03:04:30PM +0100, Ariane van der Steldt wrote:
> >> On Fri, Dec 30, 2011 at 02:42:18PM +010
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: /cvs/src/sys/u
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 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 com
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
> proble
2 2009/03/02 09:42:55 mikeb Exp $ */
+/*
+ * Copyright 2002 Niels Provos
+ * Copyright 2011 Ariane van der Steldt
+ * 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. Redistribut
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, Sep 20, 2011 at 09:47:45AM +0200, Mark Kettenis wrote:
> > Date: Tue, 20 Sep 2011 01:41:35 +0300
> > From: Paul Irofti
> >
> > 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 turn
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
>
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 05:52:09PM +0200, Otto Moerbeek wrote:
> The diff below implements utrace(2), a syscall to introduce data into
> a ktrace stream from a userland program.
>
> The interface is taken from netbsd, freebsd also has a utrace(2)
> syscall, but lacks the label argument.
>
> You
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 that pages that become free will be unmapped asap.
> This detects more use-after-free bugs. The slowdown is because of more
> unmap/mmap calls.
On Sun, Jul 03, 2011 at 09:15:21PM +0100, Owain Ainsworth wrote:
> so all allocators obey it, not just uvm_pagealloc (which is increasingly
> rarely called). This actually makes it a lot harder to deadlock the
> machine under very heavy memory pressure (uvm_pglistalloc for 7 pages
> when you have 7
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 si
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: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
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 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_fre
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 Wed, May 18, 2011 at 06:48:02PM +0200, Ariane van der Steldt wrote:
> Pmemrange being a difficult algorithm and reports of dma controllers
> being unhappy with what it serves up, plus some prodding from theo,
> caused me to write this little validation step.
>
> Very lo
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:
> >
>
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 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
> 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 dou
On Thu, May 19, 2011 at 08:28:09PM +0300, Michael Pounov wrote:
> Add AVL tree implementation and merge few RB tree related macros.
>
> If you have comments or any claims, please send me feedback
> and I will fix them.
>
> Inline patch::
> --- /usr/src/sys/sys/tree.h Mon Mar
On Thu, May 19, 2011 at 07:33:22PM +0200, Mike Belopuhov wrote:
> On Thu, May 19, 2011 at 7:25 PM, Michael Pounov 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 the right ord
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
> >
> > I would respond in-thread, but I can't find the thread that had the
> > original report that emacs-22 doesn't w
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.
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, insists
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 thi
Hi,
Pmemrange being a difficult algorithm and reports of dma controllers
being unhappy with what it serves up, plus some prodding from theo,
caused me to write this little validation step.
Very low overhead, but guaranteed to catch bugs when they happen,
instead of when finally a dma controller d
Hi,
When the sparc64 iommu fails to lookup a vaddr, it prints a message and
returns EFBIG. This cannot be recovered from and is usually indicative
of damaged pmap. Therefor, panic right here instead.
Tested on sparc64, where this diff means the difference between dropping
into single-user mode ve
On Wed, May 11, 2011 at 05:05:32PM +0200, Ariane van der Steldt wrote:
> 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.d
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 wit
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.
> >
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 change
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
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 Ap
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 replacem
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
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 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
> dif
On Tue, Apr 19, 2011 at 11:26:16AM +0600, Anton Maksimenkov wrote:
> 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.
On Mon, Apr 18, 2011 at 03:47:27PM -0600, Artur Grabowski wrote:
> A repeat of an earlier diff.
>
> Change stack and exec arguments allocation from old allocators to km_alloc(9).
> int
> fork1(struct proc *p1, int exitsig, int flags, void *stack, size_t stacksize,
> void (*func)(void *), v
On Mon, Apr 18, 2011 at 10:24:32AM +0600, Anton Maksimenkov wrote:
> 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 whe
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
> > So it turns out that my allocator is not capable of handling the pmap_prefer
> > horror. This diff exports the actual parameters
On Wed, Apr 06, 2011 at 12:12:35AM +0600, Anton Maksimenkov wrote:
> 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
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 th
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 allocation
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 c
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
=
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: /cvs/src/sys/uvm/uvm_
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
On Fri, Dec 24, 2010 at 05:14:13PM -0500, Ted Unangst wrote:
> On Fri, Dec 24, 2010 at 5:02 PM, Mark Kettenis
> wrote:
> >> Date: Fri, 24 Dec 2010 16:54:23 -0500 (EST)
> >> From: Ted Unangst
> >>
> >> increase the hard limit on i386 max data size to 2GB-1. This will allow
> >> memory hungry proc
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_ma
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 kerne
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 " on amd64),
> I added the following
On Wed, Nov 03, 2010 at 01:28:31PM +0100, David Coppa wrote:
> Ok?
>
> Index: support.c
> ===
> RCS file: /cvs/src/games/cribbage/support.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 support.c
> --- support.c 27 Oct 2009 23:59:2
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,
> uri
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
pretty much screws
> > it. Perhaps going back to the min hint for the protection and trying to
> > push just a little bit down may work?
>
> 2010/2/4 Ariane van der Steldt :
> > mmap(..., MAP_FIXED) requires a search by addr.
> > uvm_map_findspace() should also be able
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
> >> thi
On Thu, Feb 04, 2010 at 11:51:11AM +0500, Anton Maksimenkov wrote:
> 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 fun
On Tue, Feb 02, 2010 at 01:21:55AM +0500, Anton Maksimenkov wrote:
> 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_TRE
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 eve
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 revisio
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
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
>
85 matches
Mail list logo
