On Fri, Jul 02, 2010 at 08:55:30AM +1000, matthew green wrote:
>
> > On Thu, Jul 01, 2010 at 01:32:47AM +0200, Rhialto wrote:
> > > On Wed 30 Jun 2010 at 08:57:44 -0700, Chuck Silvers wrote:
> > > >- the assembler apparently now uses a different opcode for reloading
> > > > %gs
> > > > t
> On Thu, Jul 01, 2010 at 01:32:47AM +0200, Rhialto wrote:
> > On Wed 30 Jun 2010 at 08:57:44 -0700, Chuck Silvers wrote:
> > >- the assembler apparently now uses a different opcode for reloading
> > > %gs
> > > than it used to, so the check for this instruction in INTRFASTEXIT
> > >
On Thu, Jul 01, 2010 at 01:32:47AM +0200, Rhialto wrote:
> On Wed 30 Jun 2010 at 08:57:44 -0700, Chuck Silvers wrote:
> >- the assembler apparently now uses a different opcode for reloading %gs
> > than it used to, so the check for this instruction in INTRFASTEXIT
> > being the cause
On Wed 30 Jun 2010 at 08:57:44 -0700, Chuck Silvers wrote:
>- the assembler apparently now uses a different opcode for reloading %gs
> than it used to, so the check for this instruction in INTRFASTEXIT
> being the cause of a kernel trap wasn't working. I fixed the check
> to mat
hi again,
ok, I think I'm finally done with this.
changes since the previous version include:
- I redid the %fs/%gs handling on amd64 so that we always keep the user values
loaded (though the kernel curcpu pointer is in the GS.base MSR via swapgs),
and that fixed the problem with needing t
On Fri Jun 18 2010 at 04:09:30 +1000, matthew green wrote:
> > Generally speaking, performance for the uniprocessor case is, in fact,
> > preserved, because the actual bus-locking operations are patched away
> > at startup time.
> >
> > However, only x86 currently supports this, I believe. Very s
On Fri, Jun 18, 2010 at 04:09:30AM +1000, matthew green wrote:
>
> i ran a bunch of measurements for sparc64 when i changed GENERIC to be
> MP by default (it's necessary for now, until we parse the numa-like
> memory maps and avoid memory not available without depending on the CPU
> it is physical
> On Thu, Jun 17, 2010 at 12:07:43PM -0400, Matthew Mondor wrote:
> > On Thu, 17 Jun 2010 10:25:59 +
> > Andrew Doran wrote:
> >
> > > This is mainly down the fact that we need kernel_lock to bracket "legacy"
> > > sections of code that aren't preemption safe. I think MULTIPROCESSOR
> > > s
On Thu Jun 17 2010 at 12:21:41 -0400, Thor Lancelot Simon wrote:
> On Thu, Jun 17, 2010 at 12:07:43PM -0400, Matthew Mondor wrote:
> > On Thu, 17 Jun 2010 10:25:59 +
> > Andrew Doran wrote:
> >
> > > This is mainly down the fact that we need kernel_lock to bracket "legacy"
> > > sections of c
On Thu, Jun 17, 2010 at 03:27:06PM +0100, Mindaugas Rasiukevicius wrote:
> Chuck Silvers wrote:
> >
> > the updated diff is at:
> > ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl-take2.39
> >
>
> The emulation hook, which performs proc_free_pid(l->l_lid), is called before
> LWP
On Thu, Jun 17, 2010 at 12:07:43PM -0400, Matthew Mondor wrote:
> On Thu, 17 Jun 2010 10:25:59 +
> Andrew Doran wrote:
>
> > This is mainly down the fact that we need kernel_lock to bracket "legacy"
> > sections of code that aren't preemption safe. I think MULTIPROCESSOR
> > should be sent o
On Thu, 17 Jun 2010 10:25:59 +
Andrew Doran wrote:
> This is mainly down the fact that we need kernel_lock to bracket "legacy"
> sections of code that aren't preemption safe. I think MULTIPROCESSOR
> should be sent off to the glue factory but that's another discussion :-).
Is there any way
On Thu, Jun 17, 2010 at 10:25:59AM +, Andrew Doran wrote:
> > > - Re: the Linux +ucas_int() hack, [...]
> >
> > I think the hacky version is actually safe. the copyin() will have
> > fetched the page into memory and created a pmap mapping for it.
> > in a UP kernel, nothing can happen between
Chuck Silvers wrote:
>
> the updated diff is at:
> ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl-take2.39
>
The emulation hook, which performs proc_free_pid(l->l_lid), is called before
LWP gets removed from the global list - so there is a small window where LID
uniqueness is no
On Wed, Jun 16, 2010 at 03:56:44PM -0700, Chuck Silvers wrote:
> On Mon, Jun 14, 2010 at 03:25:56PM +, Andrew Doran wrote:
> > On Sun, Jun 13, 2010 at 10:59:45PM -0700, Chuck Silvers wrote:
> > > hi folks,
> > >
> > > ok, more progress. linux32 is working now and I fixed a few other bugs
> >
On Mon, Jun 14, 2010 at 03:25:56PM +, Andrew Doran wrote:
> On Sun, Jun 13, 2010 at 10:59:45PM -0700, Chuck Silvers wrote:
> > hi folks,
> >
> > ok, more progress. linux32 is working now and I fixed a few other bugs
> > along the way.
> >
> > the updated diff is in
> > ftp://ftp.netbsd.org/p
Andrew Doran wrote:
> - The dup code for fork1() code makes me uncomfortable. Maybe it's
> worthwhile changing our native code so that LIDs are always allocated
> from the PID table or something along those lines? Tend to think these
> should be globally unique with the system and not just
On Wed, Jun 16, 2010 at 10:27:16AM +0200, Joerg Sonnenberger wrote:
> On Wed, Jun 16, 2010 at 06:30:23AM +, YAMAMOTO Takashi wrote:
> > i think ucontext is more flexible because this way the kernel doesn't
> > need to know which register etc is used for tls.
The amount of code in kernel to sup
On Wed, Jun 16, 2010 at 06:30:23AM +, YAMAMOTO Takashi wrote:
> i think ucontext is more flexible because this way the kernel doesn't
> need to know which register etc is used for tls.
In many cases, the kernel has to know about the private mapping because
it has to update it on context switch
[ removed pkgsrc Cc: ]
hi,
> - mips pcb_tls. Can you use curlwp->l_private instead and add a
> cpu_lwp_setprivate() ala i386 to handle this? As it would be the same
> mechanism that we'd use for native TLS. There is a __HAVE flag for
> this in machine/types.h as far as I remember, see sy
On Sun, Jun 13, 2010 at 10:59:45PM -0700, Chuck Silvers wrote:
> hi folks,
>
> ok, more progress. linux32 is working now and I fixed a few other bugs
> along the way.
>
> the updated diff is in
> ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl-take2.36
- mips pcb_tls. Can you use
hi folks,
ok, more progress. linux32 is working now and I fixed a few other bugs
along the way.
the updated diff is in
ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl-take2.36
this patch includes:
- apply joerg's patch for amd64 TLS, reworked a bit by me
to support 32-bit p
On Mon, Jun 07, 2010 at 07:48:06AM +1000, matthew green wrote:
>
> > On Sat, Jun 05, 2010 at 01:02:12PM +1000, matthew green wrote:
> > >
> > > > - fix obreak() to honor RLIMIT_AS as well as RLIMIT_DATA.
> > > >this will affect native processes as well as linux ones,
> > > >but it seems
> On Sat, Jun 05, 2010 at 01:02:12PM +1000, matthew green wrote:
> >
> > > - fix obreak() to honor RLIMIT_AS as well as RLIMIT_DATA.
> > >this will affect native processes as well as linux ones,
> > >but it seems appropriate.
> >
> > if you're going to do this, you may as well just make
On Sat, Jun 05, 2010 at 01:02:12PM +1000, matthew green wrote:
>
> > - fix obreak() to honor RLIMIT_AS as well as RLIMIT_DATA.
> >this will affect native processes as well as linux ones,
> >but it seems appropriate.
>
> if you're going to do this, you may as well just make RLIMIT_AS and
On Sat, Jun 05, 2010 at 12:02:35AM +0100, Mindaugas Rasiukevicius wrote:
> Hello,
>
> Chuck Silvers wrote:
> >
> > I rewrote my COMPAT_LINUX changes using the 1-proc-many-LWPs model.
> > the patch is at:
> >
> > ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl-take2.23
> >
>
> I
> - fix obreak() to honor RLIMIT_AS as well as RLIMIT_DATA.
>this will affect native processes as well as linux ones,
>but it seems appropriate.
if you're going to do this, you may as well just make RLIMIT_AS and
RLIMIT_DATA refer to the same thing (and make that RLIMIT_AS.)
when implem
On Fri Jun 04 2010 at 14:11:49 -0700, Chuck Silvers wrote:
> - fix obreak() to honor RLIMIT_AS as well as RLIMIT_DATA.
>this will affect native processes as well as linux ones,
>but it seems appropriate.
No comments for the linux stuff (apart from "cool!"), but I agree this
part is approp
Hello,
Chuck Silvers wrote:
>
> I rewrote my COMPAT_LINUX changes using the 1-proc-many-LWPs model.
> the patch is at:
>
> ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl-take2.23
>
I like this patch a lot! Especially good clean-ups, as a result.
Few comments:
- Thanks for im
hi folks,
I rewrote my COMPAT_LINUX changes using the 1-proc-many-LWPs model.
the patch is at:
ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl-take2.23
this patch includes:
- joerg's patch for amd64 TLS.
- update linux syscall table (for each platform).
- support new-style (N
30 matches
Mail list logo
