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
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 <
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
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
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
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
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
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
...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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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().
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
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
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
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
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
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
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
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
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
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
(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
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
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
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
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
47 matches
Mail list logo
