headers
Bruce Evans | 1 Jun 2006 01:25
Picon

Re: [patch] Adding optimized kernel copying support - Part III

On Wed, 31 May 2006, Attilio Rao wrote:

> 2006/5/31, Suleiman Souhlal <ssouhlal <at> freebsd.org>:
>> Nice work. Any chance you could also port it to amd64? :-)
>
> Not in the near future, I think. :P

It is not useful for amd64.  An amd64 has enough instruction bandwidth
to saturate the L1 cache using 64-bit accesses although not using
32-bit accesses.  An amd64 has 64-bit integer registers which can be
accesses without the huge setup overheads and code complications for
MMX/XMM registers.  It already uses 64-bit registers or 64-bit movs
for copying and zeroing of course.  Perhaps it should use prefetches
and nontemporal writes more than it already does, but these don't
require using SSE2 instructions like nontemporal writes do for 32-bit
CPUs.

>> Does that mean it won't work with SMP and PREEMPTION?
>
> Yes it will work (even if I think it needs more testing) but maybe
> would give lesser performances on SMP|PREEMPTION due to too much
> traffic on memory/cache. For this I was planing to use non-temporal
> instructions
> (obviously benchmarks would be very appreciate).

Er, isn't its main point to fix some !SMP assumptions made in the old
copying-through-the-FPU code?  (The old code is messy due to its avoidance
of global changes.  It wants to preserve the FPU state on the stack, but
this doesn't quite work so it does extra things (still mostly locally)
that only work in the !SMP && (!SMPng even with UP) case.  Patching this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Attilio Rao | 1 Jun 2006 01:32
Picon

Re: [patch] Adding optimized kernel copying support - Part III

2006/6/1, Bruce Evans <bde <at> zeta.org.au>:
>
> >> Does that mean it won't work with SMP and PREEMPTION?
> >
> > Yes it will work (even if I think it needs more testing) but maybe
> > would give lesser performances on SMP|PREEMPTION due to too much
> > traffic on memory/cache. For this I was planing to use non-temporal
> > instructions
> > (obviously benchmarks would be very appreciate).
>
> Er, isn't its main point to fix some !SMP assumptions made in the old
> copying-through-the-FPU code?  (The old code is messy due to its avoidance
> of global changes.  It wants to preserve the FPU state on the stack, but
> this doesn't quite work so it does extra things (still mostly locally)
> that only work in the !SMP && (!SMPng even with UP) case.  Patching this
> approach to work with SMP || SMPng cases would make it messier.)
>
> The new code wouldn't behave much differently under SMP.  It just might
> be a smaller optimization because more memory pressure for SMP causes
> more cache misses for everything and there are no benefits from copying
> through MMX/XMM unless nontemporal writes are used.  All (?) CPUs with
> MMX or SSE* can saturate main memory using 32-bit instructions.  On
> 32-bit CPUs, the benefits of using MMX/XMM come from being able to
> saturate the L1 cache on some CPUs (mainly Athlons and not P[2-4]),
> and from being able to use nontemporal writes on some CPUs (at least
> AthlonXP via SSE extensions all CPUs with SSE2).

I was just speaking about the copying routine itself and not about the
SSE2 environment preserving mechanism. It remains untouched in SMP
case.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg 'groggy' Lehey | 1 Jun 2006 01:48
Picon
Favicon

Re: dump(8) performance

On Wednesday, 31 May 2006 at  8:05:21 -0700, Eugene M. Kim wrote:
> While watching the output of iostat -dxz -w10 -n100 to monitor the
> progress/performance of a dump(8) process straight to a tape, I found
> out something interesting and disappointing at the same time: The disk
> read throughput was exactly twice as high as the tape write throughput,
> throughout the entire dump phases 4 and 5, i.e. dumping actual inodes.
> Disappointing, because the tape drive utilization (%busy) was lingering
> around 35%-50% for most of the time; I didn't expect the disk would be
> the bottleneck. :p
>
> I want to believe that this indicates a bug in dump(8) which causes each
> disk block to be read twice, but being no UFS expert in any sense, I
> wonder: Could this behavior be by design, and would there be any room
> for improvement?

Without looking at the code, this seems unlikely.  But you might get
more information by attaching a ktrace to the dump process for a short
period of time (find the pid, then ktrace -p<pid> to start trace,
ktrace -p<pid> -C to stop again).  If you do that, let me see no more
than 30 lines of repetitive trace.

Greg
--
See complete headers for address and phone numbers.
Permalink | Reply | 0 comments |
headers
Michael Vince | 1 Jun 2006 03:23

Re: Is anyone working on a port of ZFS to FreeBSD

pfgshield-freebsd <at> yahoo.com wrote:

>Hello;
>
>DragonFly and NetBSD are interested, I'm sure there's interest in FreeBSD too,
>but AFAICT no one has started.
>
>Here is an interesting link:
>
>http://www.opensolaris.org/os/community/zfs/porting/
>
>cheers,
>
>Pedro.
>
>---
>
>  
>
Since this is a project that would benefit just about anyone using 
FreeBSD, it would be good to see a project like this get funding or do a 
fund raise.
As a summer of code project I would assume this would be to difficult of 
a project to for anyone but those of a fair amount of experience?

Mike

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(Continue reading)

Permalink | Reply | 14 comments |
headers
Eric Anderson | 1 Jun 2006 04:34
Favicon

Re: Is anyone working on a port of ZFS to FreeBSD

Michael Vince wrote:
> pfgshield-freebsd <at> yahoo.com wrote:
> 
>> Hello;
>>
>> DragonFly and NetBSD are interested, I'm sure there's interest in 
>> FreeBSD too,
>> but AFAICT no one has started.
>>
>> Here is an interesting link:
>>
>> http://www.opensolaris.org/os/community/zfs/porting/
>>
>> cheers,
>>
>> Pedro.
>>
>> ---
>>
>>  
>>
> Since this is a project that would benefit just about anyone using 
> FreeBSD, it would be good to see a project like this get funding or do a 
> fund raise.
> As a summer of code project I would assume this would be to difficult of 
> a project to for anyone but those of a fair amount of experience?
> 
> Mike

ZFS surely is cool, but I'm not sure how much it benefits FreeBSD
(Continue reading)

Permalink | Reply | 7 comments |
headers
pfgshield-freebsd | 1 Jun 2006 03:41
Picon
Favicon

Re: Is anyone working on a port of ZFS to FreeBSD

Hello;

--- Michael Vince <mv <at> thebeastie.org> ha scritto: 

<snip> (I forgot to mention Apple is interested in it too)

> Since this is a project that would benefit just about anyone using 
> FreeBSD, it would be good to see a project like this get funding or do a 
> fund raise.
> As a summer of code project I would assume this would be to difficult of 
> a project to for anyone but those of a fair amount of experience?
> 
> Mike
>

Back in the days when IBM released their JFS for Linux, there was a written
petition asking IBM to relax the license so that it would be ported to the
BSDs. IBM didn't accept but it was really nice to see all the BSDs together on
this.
Porting it to one BSD will help the others, but maybe (and this is mere
speculation) it would be easier for FreeBSD once Dtrace is finished/imported
and we get some extra OpenSolaris compatibility in the headers. FWIW, I'd also
like to see libumem ported.

That said, these projects usually pick up only when someone takes the flag and
starts on it's own, making it easier for an interested expert to continue and
polish the initial effort.

    Pedro.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Eric Anderson | 1 Jun 2006 05:50
Favicon

Re: Is anyone working on a port of ZFS to FreeBSD

pfgshield-freebsd <at> yahoo.com wrote:
> --- Eric Anderson <anderson <at> centtech.com> ha scritto: 
> 
> ...
>>
>> ZFS surely is cool, but I'm not sure how much it benefits FreeBSD 
>> compared to something like journaling, or adding features to our 
>> existing filesystem, or even write support for one of the already ported 
>> read-only filesystems we have (like XFS, or reiserfs).
>>
> 
> I'm afraid adding write support to XFS or reiserfs is not easy, and then
> there's the license issue. ZFS might not have the best license either but we
> can work with it. Apple's updated HFS license is also something that could be
> worked with but Apple is interested in ZFS too so it must have something
> interesting ;-).

I realize how hard getting write support for one of those is, for 
certain.    You'd still have to go through the labor with ZFS though, 
unless you are talking about read-only support for it.  I don't know 
much about licensing stuff...

> NetBSD has a Journalling Google SoC, definitely interesting if they get far.
> 
>     Pedro.

We did too last year, but it didn't complete.  I think Scott Long is 
back looking at it again (I've seen some hints of life in the p4 repo).

Eric
(Continue reading)

Permalink | Reply | 5 comments |
headers
Liudas B. | 1 Jun 2006 09:19
Picon

ANA-6922 can't detect media

Hi,

I’m trying to use ANA-6922 multi-port board on FreeBSD 6.1-BETA1. 
Works only first port when using dc driver. This is because board 
has only one ROM and second port must use shared ROM (kern/79262). I 
wrote patch for this.

But there is another problem (with or without patch). Both ports 
connected to the 100mbps switch, but driver seems can’t detect media 
type (or any media). ifconfig shows no media (no carrier). I try to 
set media auto, media 100baseTX. No luck. Switch shows, that port is 
connected (green LED on).

Here is another interesting thing. After “ifconfig dc1 up” command 
dc1 keeps up and down (dmesg shows dc1 DOWN, dc1 UP, dc1 DOWN, 
etc.). On switch LED keeps turning on and off.

Any ideas?

P.S. first board’s port works fine on FreeBSD 4.11
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Alexander Leidinger | 1 Jun 2006 09:30
Favicon

Re: [patch] Adding optimized kernel copying support - Part III

Quoting Attilio Rao <asmrookie <at> gmail.com> (from Thu, 1 Jun 2006  
01:32:12 +0200):

> 2006/6/1, Bruce Evans <bde <at> zeta.org.au>:

>> The new code wouldn't behave much differently under SMP.  It just might
>> be a smaller optimization because more memory pressure for SMP causes
>> more cache misses for everything and there are no benefits from copying
>> through MMX/XMM unless nontemporal writes are used.  All (?) CPUs with
>> MMX or SSE* can saturate main memory using 32-bit instructions.  On
>> 32-bit CPUs, the benefits of using MMX/XMM come from being able to
>> saturate the L1 cache on some CPUs (mainly Athlons and not P[2-4]),
>> and from being able to use nontemporal writes on some CPUs (at least
>> AthlonXP via SSE extensions all CPUs with SSE2).
>
> I was just speaking about the copying routine itself and not about the
> SSE2 environment preserving mechanism. It remains untouched in SMP
> case.

AFAIR the DFly FPU rework allows to use FPU/XMM instructions in their  
kernel without the need to do some manual state preserving (it's done  
automatically on demand). So one could use XMM instructions in RAID 5  
or crypto parts of the code to test if it is a performance benefit. Do  
I understand the above part right that with this patch this is also  
the case for us in the UP case, but not in the SMP case?

Bye,
Alexander.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Danny Braniss | 1 Jun 2006 11:49
Picon
Picon
Favicon

iSCSI/sendto(...)

Hi,
	on a fairly new 6.1-stable, and probably before, once in a
blue moon, sendto return error 64 (EHOSTDOWN?). but the packet seems to have
been received by the target, since i get a response, and further more,
everything keeps on working.

what is error 64?

danny

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply | 2 comments |

Gmane