Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Apr 4, 2009 02:02:07 PM, jul...@elischer.org wrote: >Hey Sergey, whatever you are using for a mail client SUCKS >real bad at the moment.. > > it's really messing up your outgoing mails.. > >note the mail below Looks like using the text mode didn't help :-( Oh, well, I g

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Hey Sergey, whatever you are using for a mail client SUCKS real bad at the moment.. it's really messing up your outgoing mails.. note the mail below Sergey Babkin wrote: Apr 2, 2009 01:03:48 AM, [1]peterjer...@optushome.com.au wrot= : >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <

Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Apr 2, 2009 01:03:48 AM, [1]peterjer...@optushome.com.au wrot= e: >On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev <[2]sobo...@freebsd.org> wrote: >>You don't really need to = do it on every execve() unconditionally. It >>could be done on de= mand in libc, so that only when thread p

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev wrote: >You don't really need to do it on every execve() unconditionally. It >could be done on demand in libc, so that only when thread pass certain >threshold, the "common page optimization code" kicks in and does its >open/mmap/etc magic. Otherwise

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Prashant Vaibhav wrote: ...and that is _exactly_ what I propose(d) in the beginning and what OSX already does. Further, keeping the shared page and functions fixed at the end of the memory space has advantages like not needing any special linking, being easily accessible for code jumps or data re

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Robert Watson wrote: Part of the point of mapping in the page at execve()-time, or fork()-time for per-process pages (which I'm not entirely convinced we need yet) is to avoid the cost of an extra device open, mmap, etc, for every execve(), which can be quite expensive. I stuck a prototype pag

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Peter Jeremy wrote: On 2009-Mar-29 08:35:45 +0800, David Xu wrote: Julian Elischer wrote: interestingly it is even feasible to have a per-thread page.. it requires that the scheduler change a page table entry tough. I will knock his door at midnight if he added such a heavy weight task in the

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. I believe somebody

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

...and that is _exactly_ what I propose(d) in the beginning and what OSX already does. Further, keeping the shared page and functions fixed at the end of the memory space has advantages like not needing any special linking, being easily accessible for code jumps or data reads, and so on [1]. The TS

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Poul-Henning Kamp wrote: In message <20090329180745.gb38...@server.vk2pj.dyndns.org>, Peter Jeremy write s: I'm assuming folks are still in love with the TSC because it still the cheapest as oppose ACPI-fast or HPET to even contemplate this? That is its major advantage. It might be feasible t

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Mon, Mar 30, 2009 at 07:32:42AM +, Poul-Henning Kamp wrote: > On systems where the ACPI or HPET hardware can be memory-mapped, I should > be equally possible to map those read-only into userland processes. Both are IO memory and contain other data. There is also the question of how "undefin

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

David Xu wrote: Julian Elischer wrote: David Xu wrote: David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doi

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

In message <20090329180745.gb38...@server.vk2pj.dyndns.org>, Peter Jeremy write s: >>I'm assuming folks are still in love with the TSC because it still the >>cheapest as oppose ACPI-fast or HPET to even contemplate this? > >That is its major advantage. It might be feasible to export all the >data

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Julian Elischer wrote: David Xu wrote: Julian Elischer wrote: David Xu wrote: David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

David Xu wrote: Julian Elischer wrote: David Xu wrote: David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doi

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Julian Elischer wrote: David Xu wrote: David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doing userland spinl

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

David Xu wrote: David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doing userland spinlock, if userland asks a

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

David Xu wrote: Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doing userland spinlock, if userland asks a page, kernel will

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Julian Elischer wrote: depends on the hardware. anyhow I was only saying it was possible, not necessarily good or even useful. I had done some works for thread private page shared by kernel and userland when I was doing userland spinlock, if userland asks a page, kernel will allocate it and

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Sun, Mar 29, 2009 at 2:07 PM, Peter Jeremy wrote: > On 2009-Mar-27 14:19:16 -0400, Alexander Sack wrote: >>I'm assuming folks are still in love with the TSC because it still the >>cheapest as oppose ACPI-fast or HPET to even contemplate this? > > That is its major advantage.  It might be feasi

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On 2009-Mar-29 08:35:45 +0800, David Xu wrote: >Julian Elischer wrote: >> interestingly it is even feasible to have a per-thread page.. >> it requires that the scheduler change a page table entry tough. > >I will knock his door at midnight if he added such a heavy weight >task in the scheduler, TL

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On 2009-Mar-27 14:19:16 -0400, Alexander Sack wrote: >On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp wrote: >> In message <49cd0405.1060...@samsco.org>, Scott Long writes: >> >>>I've been talking about this for years.  All I need is help with the VM >>>magic to create the page on fork.  I als

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

David Xu wrote: Julian Elischer wrote: Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Mar 27, 2009, at 11:30 AM, Scott Long wrote: Robert Watson wrote: On Fri, 27 Mar 2009, Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global da

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Julian Elischer wrote: Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getg

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Fri, Mar 27, 2009 at 7:25 PM, Jason Evans wrote: > Robert Watson wrote: >> >> On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: >>> >>> In message , >>> Robert Wats on writes: >>> In which case user application threads will need to know their CPU [...] >>> >>> Didn't jemalloc solve that proble

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Robert Watson wrote: On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: In message , Robert Wats on writes: In which case user application threads will need to know their CPU [...] Didn't jemalloc solve that problem once already ? I think jemalloc implements thread-affinity for arenas rather t

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: In message , Robert Wats on writes: In which case user application threads will need to know their CPU [...] Didn't jemalloc solve that problem once already ? I think jemalloc implements thread-affinity for arenas rather than CPU-affinity in

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

In message , Robert Wats on writes: >In which case user application threads will need to >know their CPU [...] Didn't jemalloc solve that problem once already ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: In message , Robert Wats on writes: I guess interesting questions are whether (a) it would be desirable to have per-page, per-cpu, or per-thread mappings. If there are non-synchronized TSCs, then there might be some interesting advantages to a p

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

In message , Robert Wats on writes: >I guess interesting questions are whether (a) it would be desirable to have >per-page, per-cpu, or per-thread mappings. If there are non-synchronized >TSCs, then there might be some interesting advantages to a per-CPU page. Rule #3: The only thing w

Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Fri, 27 Mar 2009, Sergey Babkin wrote: Would not a normal mmap be duplicated on fork? I'd do it as a small pseudo-= driver that allows to mmap this page. Then libc would open this pseudo-d= evice and mmap it, either in the on-load handler or on the first call of= gettimeofday().

Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Would not a normal mmap be duplicated on fork? I'd do it as a small pseudo-= driver that allows to mmap this page. Then libc would open this pseudo-d evice and mmap it, either in the on-load handler or on the first call of gettimeofday(). I think, that should be it, no specia

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Hi, Scott & all-- On Mar 27, 2009, at 11:30 AM, Scott Long wrote: Robert Watson wrote: On Fri, 27 Mar 2009, Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and an

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Scott Long wrote: Robert Watson wrote: On Fri, 27 Mar 2009, Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. interestingly it i

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Robert Watson wrote: On Fri, 27 Mar 2009, Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Fri, 27 Mar 2009, Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getg

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Fri, 27 Mar 2009, Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getg

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp wrote: > In message <49cd0405.1060...@samsco.org>, Scott Long writes: > >>I've been talking about this for years.  All I need is help with the VM >>magic to create the page on fork.  I also want two pages, one global >>for gettimeofday (and any ot

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

In message <49cd0405.1060...@samsco.org>, Scott Long writes: >I've been talking about this for years. All I need is help with the VM >magic to create the page on fork. I also want two pages, one global >for gettimeofday (and any other global data we can think of) and one >per-process for static

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. Scott Sergey Babkin wrote: (Sorr

Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

(Sorry for the top quoting). Probably the best implementation of gettimeofd= ay() is to have a page in the kernel mapped read-only to all the user pr= ocesses. Put the kernel's idea of time into this page. Then getting the = time becomes a simple read (OK, two reads, to make sure

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Prashant Vaibhav wrote: > The primary idea is to improve the performance and resolution of > gettimeofday() and friends by creating a efficient userspace implementation > of these functions, along with some supporting modifications to the kernel. Are you aware of CLOCK_*_FAST family of timecounte

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

In message <17560ccf0903270555oe7d1652p7414a221aa2d6...@mail.gmail.com>, Prashant Vaibhav writes: >>[...] these must provide a monotonic timescale when queried interleaved >> ? Be aware that the TSC may not be, and may not stay synchronized across >> multiple cores. > >The TSC is documented to be

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

Poul-Henning, Thanks for the feedback! >[...] these must provide a monotonic timescale when queried interleaved > ? Be aware that the TSC may not be, and may not stay synchronized across > multiple cores. The TSC is documented to be monotonically increasing across all x86 processors that impleme

Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

In message <17560ccf0903260551v1f5cba9eu87727c0bae7b...@mail.gmail.com>, Prasha nt Vaibhav writes: >The gettimeofday() function's implementation will then be >changed to read the timestamp counter (TSC) from the processor, and use the >reading in conjunction with the timing info exported by the ke

Improving the kernel/i386 timecounter performance (GSoC proposal)

Hi everyone, I'm a potential Google Summer of Code applicant, proposing to work on improving the timecounter performance in the FreeBSD kernel (suggestion from Timecounter Performance Improvements). My qualifications are mentioned