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 guess
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 pass
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
On 2009-Mar-30 18:45:30 -0700, Maxim Sobolev sobo...@freebsd.org 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
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
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 undefined
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
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 to
...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
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
Peter Jeremy wrote:
On 2009-Mar-29 08:35:45 +0800, David Xu davi...@freebsd.org 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
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
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
On 2009-Mar-27 14:19:16 -0400, Alexander Sack pisym...@gmail.com wrote:
On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp p...@phk.freebsd.dk 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
On 2009-Mar-29 08:35:45 +0800, David Xu davi...@freebsd.org 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
On Sun, Mar 29, 2009 at 2:07 PM, Peter Jeremy
peterjer...@optushome.com.au wrote:
On 2009-Mar-27 14:19:16 -0400, Alexander Sack pisym...@gmail.com 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
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
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
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
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
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
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
On Fri, Mar 27, 2009 at 7:25 PM, Jason Evans jas...@freebsd.org wrote:
Robert Watson wrote:
On Fri, 27 Mar 2009, Poul-Henning Kamp wrote:
In message alpine.bsf.2.00.0903272303040.12...@fledge.watson.org,
Robert Wats on writes:
In which case user application threads will need to know their
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
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
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
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 implement
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
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 timecounters
(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
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:
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 data
On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp p...@phk.freebsd.dk 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
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
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
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
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
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
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
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
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().
In message alpine.bsf.2.00.0903272254460.12...@fledge.watson.org, 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
On Fri, 27 Mar 2009, Poul-Henning Kamp wrote:
In message alpine.bsf.2.00.0903272254460.12...@fledge.watson.org, 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,
In message alpine.bsf.2.00.0903272303040.12...@fledge.watson.org, 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
On Fri, 27 Mar 2009, Poul-Henning Kamp wrote:
In message alpine.bsf.2.00.0903272303040.12...@fledge.watson.org, 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
Robert Watson wrote:
On Fri, 27 Mar 2009, Poul-Henning Kamp wrote:
In message alpine.bsf.2.00.0903272303040.12...@fledge.watson.org,
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
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
Improvementshttp://www.freebsd.org/projects/ideas/index.html#p-timecounter-perf).
My qualifications are mentioned
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 kernel
48 matches
Mail list logo
