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

2009-03-30 Thread Poul-Henning Kamp
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

hot-attach SATA drive

2009-03-30 Thread Andriy Gapon
Recently I tried to hot-attach a SATA drive to a running system. Controller is ICH9 in AHCI mode. Physically/electronically everything went smoothly, the drive spun-up. Then I tried to detach and re-attach all channels with no devices on them using atacontrol. I did it 3 times to be sure, but no

Re: hot-attach SATA drive

2009-03-30 Thread Alexander Motin
Andriy Gapon wrote: > Recently I tried to hot-attach a SATA drive to a running system. > Controller is ICH9 in AHCI mode. Physically/electronically everything went > smoothly, the drive spun-up. Then I tried to detach and re-attach all channels > with no devices on them using atacontrol. I did it 3

Re: hot-attach SATA drive

2009-03-30 Thread Andriy Gapon
on 30/03/2009 14:14 Alexander Motin said the following: > Andriy Gapon wrote: >> Recently I tried to hot-attach a SATA drive to a running system. >> Controller is ICH9 in AHCI mode. Physically/electronically everything went >> smoothly, the drive spun-up. Then I tried to detach and re-attach all >

Re: Shared Disk/Transactional/Distributed file system (GSoC Proposal)

2009-03-30 Thread Aram Havarneanu
2009/3/30 Tim Kientzle : > Aram Havarneanu wrote: >> >> I have been giving some thought lately on some ideas I would like to >> do for Google Summer of Code. I haven't posted my application yet, as >> I hope to get some feedback first. > > An interesting idea, but it sounds much too > ambitious for

Re: Shared Disk/Transactional/Distributed file system (GSoC Proposal)

2009-03-30 Thread Aram Havarneanu
Oh, and of course, doing stuff with ZFS will mean that (Open)Solaris and Mac OS X will benefit as well, which I see as a good thing. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, sen

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

2009-03-30 Thread Joerg Sonnenberger
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: hot-attach SATA drive

2009-03-30 Thread Alexander Motin
Andriy Gapon wrote: > on 30/03/2009 14:14 Alexander Motin said the following: >> Andriy Gapon wrote: >>> Recently I tried to hot-attach a SATA drive to a running system. >>> Controller is ICH9 in AHCI mode. Physically/electronically everything went >>> smoothly, the drive spun-up. Then I tried to d

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

2009-03-30 Thread Scott Long
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)

2009-03-30 Thread Tim Kientzle
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)

2009-03-30 Thread Prashant Vaibhav
...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)

2009-03-30 Thread Maxim Sobolev
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)

2009-03-30 Thread Maxim Sobolev
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)

2009-03-30 Thread Maxim Sobolev
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)

2009-03-30 Thread David Xu
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