headers
Jeremie Le Hen | 2 Apr 2012 17:11

Re: Prefaulting for i/o buffers

Hi,

On Sat, Feb 25, 2012 at 08:46:31PM +0100, Pawel Jakub Dawidek wrote:
> 
> I did not implement rangelocking for ZFS. It came with ZFS when I ported
> it. Until we want to merge changes from upstream (which is now IllumOS)
> we don't want to make huge changes just for the sake of proving that
> this is general purpose mechanism used by more than one file system.
> 
> Attilio, don't get me wrong. In 99% cases it is good to make code more
> general and more universal and reusable, but we can't ignore reality.
> 
> There are reasons why file systems like XFS, ReiserFS and others where
> never fully ported. I'm not saying VFS complexity was the only reason,
> but I'm sure it was one of them.
> 
> Our VFS is very UFS-centric. We make so many assumptions that sounds
> fine only for UFS. I saw plenty of those while working on ZFS, like:
> 
> - "Every file system needs cache. Let's make it general, so that all file
>   systems can use it!" Well, for VFS each file system is a separate
>   entity, which is not the case for ZFS. ZFS can cache one block only
>   once that is used by one file system, 10 clones and 100 snapshots,
>   which all are separate mount points from VFS perspective.
>   The same block would be cached 111 times by the buffer cache.
> 
> - "rmdir(2) on a mountpoint is bad idea, let's deny it at VFS level."
>   It is bad idea, indeed, but in ZFS it is a nice way to remove snapshot
>   by rmdiring .zfs/snapshot/≤name> directory.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Evans | 2 Apr 2012 20:04
Gravatar

TLS on ARM and MIPS

I've been working on integrating jemalloc back into FreeBSD's libc, and ran into the lack of TLS on ARM and
MIPS.  Is this something that's likely to be addressed soon?  If not, I'm going to have to modify libthr to
deal with TSD bootstrapping issues -- FreeBSD's pthreads implementation *loves* to call malloc. =(

While I'm asking about TLS, it's worth asking whether any of the other platforms still lack TLS support for
non-PIC binaries.  If so, that will force the TSD issue anyway.

Thanks,
Jason_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 14 comments |
headers
Oleksandr Tymoshenko | 2 Apr 2012 20:29
Picon
Favicon

Re: TLS on ARM and MIPS

On 02/04/2012 11:04 AM, Jason Evans wrote:
> I've been working on integrating jemalloc back into FreeBSD's libc, and ran into the lack of TLS on ARM and
MIPS.  Is this something that's likely to be addressed soon?  If not, I'm going to have to modify libthr to
deal with TSD bootstrapping issues -- FreeBSD's pthreads implementation *loves* to call malloc. =(
>
> While I'm asking about TLS, it's worth asking whether any of the other platforms still lack TLS support for
non-PIC binaries.  If so, that will force the TSD issue anyway.

How old is your source base?

TLS support for ARM and MIPS has been committed about month ago.
Revisions r232577-r232582 and r233106,r233107 fixes for ARM.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 13 comments |
headers
Jason Evans | 2 Apr 2012 22:31
Gravatar

Re: TLS on ARM and MIPS

On Apr 2, 2012, at 11:29 AM, Oleksandr Tymoshenko wrote:
> On 02/04/2012 11:04 AM, Jason Evans wrote:
>> I've been working on integrating jemalloc back into FreeBSD's libc, and ran into the lack of TLS on ARM and
MIPS.  Is this something that's likely to be addressed soon?  If not, I'm going to have to modify libthr to
deal with TSD bootstrapping issues -- FreeBSD's pthreads implementation *loves* to call malloc. =(
>> 
>> While I'm asking about TLS, it's worth asking whether any of the other platforms still lack TLS support
for non-PIC binaries.  If so, that will force the TSD issue anyway.
> 
> How old is your source base?
> 
> TLS support for ARM and MIPS has been committed about month ago.
> Revisions r232577-r232582 and r233106,r233107 fixes for ARM.

I'm currently running sources from March 24, but I don't have ARM or MIPS hardware.  Can we remove the NO_TLS
definitions in src/lib/libc/stdlib/malloc.c?  I can't test the result, of course…

Thanks,
Jason_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 12 comments |
headers
Oleksandr Tymoshenko | 2 Apr 2012 23:15
Gravatar

Re: TLS on ARM and MIPS

On 02/04/2012 1:31 PM, Jason Evans wrote:
> On Apr 2, 2012, at 11:29 AM, Oleksandr Tymoshenko wrote:
>> On 02/04/2012 11:04 AM, Jason Evans wrote:
>>> I've been working on integrating jemalloc back into FreeBSD's libc, and ran into the lack of TLS on ARM
and MIPS.  Is this something that's likely to be addressed soon?  If not, I'm going to have to modify libthr to
deal with TSD bootstrapping issues -- FreeBSD's pthreads implementation *loves* to call malloc. =(
>>>
>>> While I'm asking about TLS, it's worth asking whether any of the other platforms still lack TLS support
for non-PIC binaries.  If so, that will force the TSD issue anyway.
>>
>> How old is your source base?
>>
>> TLS support for ARM and MIPS has been committed about month ago.
>> Revisions r232577-r232582 and r233106,r233107 fixes for ARM.
>
> I'm currently running sources from March 24, but I don't have ARM or MIPS hardware.  Can we remove the NO_TLS
definitions in src/lib/libc/stdlib/malloc.c?  I can't test the result, of course…

How do I test it? Will running buildword on MIPS device with
these changes be sufficient? Or do we have specific tests for it?
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 11 comments |
headers
Jason Evans | 2 Apr 2012 23:23
Gravatar

Re: TLS on ARM and MIPS

On Apr 2, 2012, at 2:15 PM, Oleksandr Tymoshenko wrote:
> On 02/04/2012 1:31 PM, Jason Evans wrote:
>> 
>> Can we remove the NO_TLS definitions in src/lib/libc/stdlib/malloc.c?  I can't test the result, of course…
> 
> How do I test it? Will running buildword on MIPS device with
> these changes be sufficient? Or do we have specific tests for it?

I typically two two rounds of buildworld/installworld/reboot to make sure that the newly installed
toolchain still works.  This paranoia is mainly to catch problems with static binaries, which won't
change in this case, so one round is probably enough.

Jason_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 10 comments |
headers
Oleksandr Tymoshenko | 4 Apr 2012 02:41
Gravatar

Re: TLS on ARM and MIPS

On 02/04/2012 2:23 PM, Jason Evans wrote:
> On Apr 2, 2012, at 2:15 PM, Oleksandr Tymoshenko wrote:
>> On 02/04/2012 1:31 PM, Jason Evans wrote:
>>>
>>> Can we remove the NO_TLS definitions in src/lib/libc/stdlib/malloc.c?  I can't test the result, of course…
>>
>> How do I test it? Will running buildword on MIPS device with
>> these changes be sufficient? Or do we have specific tests for it?
>
> I typically two two rounds of buildworld/installworld/reboot to make sure that the newly installed
toolchain still works.  This paranoia is mainly to catch problems with static binaries, which won't
change in this case, so one round is probably enough.

I tested it for MIPS - works fine. Unfortunately I don't have
ARM hardware that works with HEAD so can't test ARM part of the change.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 9 comments |
headers
John Baldwin | 4 Apr 2012 18:00
Picon
Favicon

Re: [PATCH] Add ktrace records for user page faults

On Monday, May 02, 2011 3:37:19 pm John Baldwin wrote:
> One thing I have found useful is knowing when processes are in the kernel 
> instead of in userland.  ktrace already provides records for syscall 
> entry/exit.  The other major source of time spent in the kernel that I've seen 
> is page fault handling.  To that end, I have a patch that adds ktrace records 
> to the beginning and end of VM faults.  This gives a pair of records so a user 
> can see how long a fault took (similar to how one can see how long a syscall 
> takes now).  Sample output from kdump is below:
> 
>  47565 echo     CALL  mmap(0x800a87000,0x179000,PROT_READ|
> PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0)
>  47565 echo     RET   mmap 34370777088/0x800a87000
>  47565 echo     PFLT  0x800723000 VM_PROT_EXECUTE
>  47565 echo     RET   KERN_SUCCESS
>  47565 echo     CALL  munmap(0x800887000,0x179000)
>  47565 echo     RET   munmap 0
>  47565 echo     PFLT  0x800a00000 VM_PROT_WRITE
>  47565 echo     RET   KERN_SUCCESS
> 
> The patch is available at www.freebsd.org/~jhb/patches/ktrace_fault.patch and 
> included below.

I've updated this based on some previous feedback.  It now uses 'PRET'
instead of 'RET' for return from a page fault.  I've also made it possible
for the MD layers to pass a non-truncated address, though those changes are
not part of this patch.  The updated patch is available at the URL above.
I'd like to merge it in if there are no objections.  If folks have other
suggestions than 'PFLT' and 'PRET' for the markers for page faults that
is fine with me.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Baldwin | 4 Apr 2012 20:33
Picon
Favicon

EVENTHANDLER()'s

So many years ago (2004), you removed support for "fast" EVENTHANDLER() 
objects.  I was looking at this today and I kind of think we should actually 
undo that, but perhaps instead what we should do is make all EVENTHANDLER()'s 
"fast".  No one creates eventhandlers with dynamic names (nor have they ever 
AFAIK), they all have static names.  However, each time someone calls 
EVENTHANDLER_INVOKE() we do an O(n) loop with strcmp's to lookup the list by 
it's name via a string.  It seems to me that we would do just fine with having 
all the eventhandler lists be global variables like the old "fast" variants 
and the string "tag" passed to all the EVENTHANDLER macros would just be used 
to set the variable name (exactly like the old "fast" variants).  This would 
remove all the O(n) lookups, and we could further optimize _INVOKE() to not do 
any locking if the list is empty to avoid overhead in the case where there are 
no active hooks.

--

-- 
John Baldwin
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Poul-Henning Kamp | 4 Apr 2012 23:03
Picon
Favicon

Re: EVENTHANDLER()'s

In message <201204041433.05652.jhb <at> freebsd.org>, John Baldwin writes:

You are probably right.

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk <at> FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |

Gmane