Re: SATA is to slow comparing with linux
on 30/09/2009 19:47 Oliver Lehmann said the following: > Robert Noland wrote: > >> I would also be curious how that ahci driver from -CURRENT is performing >> relative to other implementations. > > I tried 8.0-RC1-i386.iso but the ahci driver didn't picked up my promise > nor my VIA controller. So all the numbers now for the "old" ata driver. What mode do you have set for your controllers in BIOS? AHCI or IDE/Legacy/etc? -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: tuning zfs for large file reads
Can't really help you but here is couple of notes: 1. iostat -x output seems to be even more informative for disk I/O 2. Despite large amount of RAM (8GB) your ZFS ARC size stays at its minimum value near just 200MB. Not sure if this plays significant role in the performance issue, but perhaps something to look at. -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: monitoring per-process disk io
on 30/09/2010 21:02 R.P. Aditya said the following: > I'm trying to monitor, over the long-term, per-process disk IO (a > counter of bytes read and written per pid would be ideal). > > I currently monitor per pid cpu and memory usage using the SNMP > Host-Resources MIB, however I don't see any oids for io (disk or > otherwise) per oid. > > The closest I've come to finding what I want -- per-process disk IO > stats -- is the Linux tool dstat -- something like "screenshot 3" at: > > http://dag.wieers.com/home-made/dstat/ > > which is the output of: > > dstat -c --top-cpu -d --top-bio --top-latency > > would be good...iostat, vmstat don't give that sort of info... > > any suggestions or hints? 1) top -m io 2) rolling your own customized monitoring using dtrace -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: TTY task group scheduling
on 18/11/2010 13:04 O. Hartmann said the following: > On 11/18/10 02:30, grarpamp wrote: >> Just documenting regarding interactive performance things. >> This one's from Linux. >> >> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 > > Well, > it would be nice to have those improvements in FreeBSD, but I doubt this will > make > it in due time to FreeBSD's kernel. Well, I think that those improvements apply only to a very specific usage pattern and are greatly over-hyped. P.S. What is the due time, BTW? -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: TTY task group scheduling
on 18/11/2010 20:56 Alexander Best said the following: > On Thu Nov 18 10, Matthew D. Fuller wrote: >> On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of >> Alexander Best, and lo! it spake thus: >>> >>> judging from the videos the changes are having a huge impact imo. >> >> Well, my (admittedly limited, and certainly anecdotal) experience is >> that Linux's interactive response when under heavy load was always >> much worse than FreeBSD's. So maybe that's just them catching up to >> where we already are ;) > > well...i tried playing back a 1080p vide files while doing > `make -j64 buildkernel` and FreeBSD's interactivity seems far from perfect. > > it might be possible that linux'es interactivity was worse than freebsd's, > but still this patch should be evaluated for freebsd. in this particular case > it seems linux now does better than freebsd. You do realize that there are many more variables for such a test than just "1080p video" and "make -j64 buildkernel"? Let's not forget about hardware, video drivers, player capabilities, exact kind of the video (you know, 1080p alone doesn't tell much). Besides, someone might be interested in running -j64 on his 1,2,4-core desktop system, but it's definitely not me. I prefer to be reasonable. I am not saying that our scheduler (ULE) is perfect. I don't even say that it's better (in whatever comparison system) than Linux scheduler X. I say that I wouldn't spend my time improving system behavior in a scenario like this. I compile stuff very frequently (kernels, ports, world) while browsing web, reading email, doing various "desktop stuff", sometimes watching videos from the web (like e.g. trailers). On this machine/hardware I have never personally felt a need for improvements in the scheduler. And I run KDE4 with all bells and whistles enabled. YMMV. P.S. I don't discourage anyone from improving our scheduler, I even do encourage that. -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: TTY task group scheduling
on 19/11/2010 00:55 Daniel Nebdal said the following: > On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev wrote: >> On Thu, 18 Nov 2010 18:56:35 + >> Alexander Best wrote: >>> well...i tried playing back a 1080p vide files while doing >>> `make -j64 buildkernel` and FreeBSD's interactivity seems far from >>> perfect. >> >> One thing that just begs to be asked: since when decoding 1080p became >> an interactive task? >> > > Strictly speaking it isn't - but displaying it is a timing-sensitive > task that isn't CPU- or I/O-bound, and scheduling-wise that probably Well, I am not sure if I can agree about CPU-bound-ness. Depends on the exact video file, of course, but certain high-quality 1080p are very CPU intensive unless decoding is offloaded from the CPU. Depends on decoder code too. I had some videos that were CPU-bound on my Athlon II X2 250 with then-version of mplayer from ports. YMMV. -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: TTY task group scheduling
on 19/11/2010 11:46 Bruce Cran said the following: > [removed current@ and stable@ from the Cc list] > > On Fri, 19 Nov 2010 15:41:29 +1100 > Andrew Reilly wrote: > >> On Linux. Have you ever seen those sorts of UI problems on FreeBSD? >> I don't watch much video on my systems, but I haven't seen that. >> FreeBSD has always been good at keeping user-interactive processes >> responsive while compiles or what-not are going on in the background. > > I've definitely seen problems when running builds in an xterm. I've > often resorted to canceling it and running it on a syscons console > instead to improve performance. > So, what was it a problem with scheduler or with, e.g., "something X" being too slow rendering glyphs? Who can tell... -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: TTY task group scheduling
on 18/11/2010 22:20 Julian Elischer said the following: > tty grouping is a variant of what we used to have at one stage which is > a "kernel schedulable entity group".. KSEG Or rather, I think, a concrete application of a variant of that. > the idea is that all items in a group share some characteristic and some > amount > of resources. > > We stripped the KSEG out of the picture because it really complicated the > picture. Yes, unfortunately. One can think about a number of applications for hierarchical schedulable resources. Even one-level group scheduling could be a very useful subcase. BTW, http://www.mjmwired.net/kernel/Documentation/cgroups.txt -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
tlb shootdown
Anyone knows of a benchmark/test that can measure/demonstrate difference in tlb shootdown performance (or its lack)? -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: tlb shootdown
on 02/06/2011 15:02 Ivan Voras said the following: > On 01/06/2011 13:11, Andriy Gapon wrote: >> >> Anyone knows of a benchmark/test that can measure/demonstrate difference in >> tlb >> shootdown performance (or its lack)? > > The "tlb" utility from lmbench may help you. Just because it's named tlb and I asked for tlb something? :) tlb - TLB size and latency benchmark ... tlb tries to determine the size, in pages, of the TLB. The largest amount of memory it will examine is len bytes. ... Once the TLB boundary is located tlb reports the TLB miss latency as the TLB latency for twice as many pages as the TLB can hold. I am not this will tell anything about TLB _shootdown_ performance of SMP systems. Perhaps I wasn't specific enough in my original question. -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: http://www.freebsd.org/marketing/os-comparison.html
on 30/08/2011 16:45 Paul Ambrose said the following: > I do not believe the current status of DTrace is appropriate for promoting > > 1. DTrace is an experimental function or Semi-finished products. The kernel > dtrace support is ok, but the userland support is far from completion(at > least the pid provider has many bugs) > > 2 the FreeBSD implementation is different from Solaris/Mac OS X. The > DTraceToolkit, which has many amazing feature, can not 100% works on > FreeBSD, and there is no doc to identify the difference. > > 3 There is a missing feature list about DTrace, but no schedule list about > when to fix it. 4. There is a missing developer/maintainer for DTrace on FreeBSD. Nevertheless the kernel DTrace is quite usable and useful for kernel debugging. -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: http://www.freebsd.org/marketing/os-comparison.html
on 30/08/2011 18:39 Andriy Gapon said the following: > 4. There is a missing developer/maintainer for DTrace on FreeBSD. I probably should clarify this point: it doesn't have to be *the* maintainer, a collective maintainer is also perfect. Thus, contributions are very welcome. > Nevertheless the kernel DTrace is quite usable and useful for kernel > debugging. -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: ffmpeg & ULE
on 18/10/2011 14:30 Ivan Klymenko said the following: > В Tue, 18 Oct 2011 12:04:36 +0300 > Urmas Lett пишет: > >> Hello. >> >> Why is ffmpeg -threads massively slower with ULE than 4BSD? >> >> ffmpeg preset veryfast with sched_bsd: >> real1m49.407s >> user6m53.932s >> sys 0m1.700s >> >> ffmpeg preset veryfast with sched_ule: >> real2m52.711s >> user6m50.310s >> sys 0m1.582s >> >> #uname -a >> FreeBSD 9.0-RC1 FreeBSD 9.0-RC1 #0: Mon Oct 17 20:32:29 EEST >> >> > > probably because you have a system processor with 2 cores...? > if yes - then use the 4BSD...it is better for the two cores... IMHO Do you have any facts to substantiate your claim? -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: ffmpeg & ULE
on 18/10/2011 18:27 Ivan Klymenko said the following: > What tests should I do with ffmpeg? I don't know - what the original poster did? I.e. compare ffmpeg multithreaded performance with different schedulers. -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
on 19/12/2011 17:50 Nathan Whitehorn said the following: > The thing I've seen is that ULE is substantially more enthusiastic about > migrating processes between cores than 4BSD. Hmm, this seems to be contrary to my theoretical expectations. I thought that with 4BSD all threads that were not in one of the following categories: - temporary pinned - bound to cpu in kernel via sched_bind - belong to a cpu set which a strict subset of a total set were placed onto a common queue that was shared by all cpus. And as such I expected them to get picked up by the cpus semi-randomly. In other words, I thought that it was ULE that took into account cpu/cache affinities while 4BSD was deliberately entirely ignorant of those details. -- Andriy Gapon ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: I like iostat, but...
On 23/09/2014 00:22, David Wolfskill wrote:
> ... I rather wish I could get the same information via sysctl. (Well,
> something seems to be available via the "opaque" kern.devstat.all
> sysctl(8) variable, but sysctl(8) doesn't display all of it, and parsing
> it seems as if that would require knowledge about the internals of the
> system where the data were acquired.)
Perhaps sysutils/devstat could be of help?
> If iostat(8) could be taught to (optionally) provide a timestamp, that
> might suffice.
>
> The problem I'm trying to solve is this: I need to be able to acquire
> various resource counters (along with timestamps), so I can post-process
> the acquired data (generally, on a system other than the one where the
> data were gathered) in order to be able to see how the
> resource-consumption changes over the duration of a moderately
> long-running task (typically. 0.5 - 8 hrs.).
>
> I have (with some success) cobbled up a shell script to do much of
> this. (And yes, I've measured the behavior of some typical workloads
> in this environment vs. merely running the workload under "/usr/bin/time
> -lpo", with 5 test iterations for each, there was no statistically
> significant difference with a 95% confidence interval.)
>
> The script:
>
> * Parses its arguments, and from that information constructs a command
> line (which invokes sysctl(8), and (optionally) netstat(1), and
> pipes that output through awk(1)).
>
> * Determines the current time-of-day ("date +%s")
>
> * Enters a loop, which:
> + "eval"s the constructed command line (causing a timestamped line of
> information to be spat out standard output); the timestamp is from
> the most-recently-acquired time-of-day.
> + Determines the current time-of-day ("date +%s").
> + Based on the desired sampling interval, calculates the number of
> seconds to sleep. (If I could get strftime to format fractional
> seconds, that could be handy.)
> + Sleeps for the calculated interval.
> + Determines the current time-of-day ("date +%s").
>
> And for most things I care about, it works fairly well.
>
> Further, I do this as a shell script precisely so I don't need to build
> a new version of the tool for a new target system: the script purposely
> only requires tools that are in base FreeBSD, and requires no special
> privilege to use.
>
> For some sample graphs I have generated from this kind of data, please
> see <http://www.catwhisker.org/~david/FreeBSD/bmake/>.
>
> I believe that having an ability to correlate the "iostat -x"
> information with the CPU, load average, and memory utilization would be
> useful -- but I don't see a reasonable way to go about it. If anyone
> has suggestions, I'm listening. :-}
--
Andriy Gapon
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
