Re: an alternative to powerpoint
On Thu, Jul 22, 2010 at 05:19:25PM +0200, Oliver Fromme wrote: > Ivan Voras wrote: > > On 07/13/10 06:15, Luigi Rizzo wrote: > > > Have fun, it would be great if you could report how it works > > > on fancy devices (iphone, ipad, androids...) > > > > For what it's worth, it doesn't work at all on Android :) (and the > > layout is messed up) > > It works pretty well on my Nexus One (Android 2.2) with > the default browser. good. There were several changes since the initial version just to improve compatibility with other browsers -- among other things, in included navigation buttons on the bottom line so you can use it on phones and similar devices. At the moment the 'distributed' version does not work with opera-mini due to the peculiar way opera-mini handles javascript cheers luigi > Best regards >Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "A language that doesn't have everything is actually easier > to program in than some that do." > -- Dennis M. Ritchie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: envy24 driver broken
Ok, here's where I am with this.
I'm currently using the Audiophile for the sake of simplicity (I'm assuming
that if the Audiophile works properly, the Delta 66 probably will too).
/dev/sndstat, at maximum verbosity, looks like:
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0: at io
0xac00:32,0xa880:16,0xa800:16,0xa480:64 irq 17 [MPSAFE] (5p:1v/3r:1v channels
duplex default)
snddev flags=0x2e2
[pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x2100,
0x0004
interrupts 0, underruns 0, feed 0, ready 0
[b:16384/2048/8|bs:16384/8192/2]
channel flags=0x2100
{userland} -> feeder_mixer(0x00200010) -> {hardware}
[pcm0:play:dsp0.p1]: spd 8000, fmt 0x0018, flags 0x,
0x
interrupts 0, underruns 0, feed 0, ready 0 [b:32768/16384/2|bs:0/0/0]
channel flags=0x0
{userland} -> feeder_root(0x) -> {hardware}
[pcm0:play:dsp0.p2]: spd 8000, fmt 0x0018, flags 0x,
0x
interrupts 0, underruns 0, feed 0, ready 0 [b:32768/16384/2|bs:0/0/0]
channel flags=0x0
{userland} -> feeder_root(0x) -> {hardware}
[pcm0:play:dsp0.p3]: spd 8000, fmt 0x0018, flags 0x,
0x
interrupts 0, underruns 0, feed 0, ready 0 [b:32768/16384/2|bs:0/0/0]
channel flags=0x0
{userland} -> feeder_root(0x) -> {hardware}
[pcm0:play:dsp0.p4]: spd 8000, fmt 0x0018, flags 0x,
0x
interrupts 0, underruns 0, feed 0, ready 0 [b:32768/16384/2|bs:0/0/0]
channel flags=0x0
{userland} -> feeder_root(0x) -> {hardware}
pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 8000, fmt 0x0018,
flags 0x1000, 0x
interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:0/0/0]
channel flags=0x1000
{userland} -> feeder_root(0x) -> {hardware}
[pcm0:record:dsp0.r0]: spd 48000, fmt 0x00200010, flags 0x2100,
0x0005
interrupts 0, overruns 0, feed 0, hfree 16384, sfree 16384
[b:16384/2048/8|bs:16384/8192/2]
channel flags=0x2100
{hardware} -> feeder_root(0x00200010) -> feeder_mixer(0x00200010) ->
{userland}
[pcm0:record:dsp0.r1]: spd 8000, fmt 0x0018, flags 0x,
0x
interrupts 0, overruns 0, feed 0, hfree 32768, sfree 0
[b:32768/16384/2|bs:0/0/0]
channel flags=0x0
{hardware} -> feeder_root(0x) -> {userland}
[pcm0:record:dsp0.r2]: spd 8000, fmt 0x0018, flags 0x,
0x
interrupts 0, overruns 0, feed 0, hfree 32768, sfree 0
[b:32768/16384/2|bs:0/0/0]
channel flags=0x0
{hardware} -> feeder_root(0x) -> {userland}
pcm0:record:dsp0.r0[pcm0:virtual:dsp0.vr0]: spd 8000, fmt 0x0018,
flags 0x1000, 0x
interrupts 0, overruns 0, feed 0, hfree 0, sfree 0 [b:0/0/0|bs:0/0/0]
channel flags=0x1000
{hardware} -> feeder_root(0x) -> {userland}
File Versions:
$FreeBSD: src/sys/dev/sound/pci/envy24.c,v 1.17.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/isa/sndbuf_dma.c,v 1.4.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder_format.c,v 1.1.2.1.2.1 2009/10/25
01:10:29 kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/vchan.c,v 1.37.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/sound.c,v 1.123.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder_eq.c,v 1.1.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder.c,v 1.45.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder_chain.c,v 1.1.2.1.2.1 2009/10/25
01:10:29 kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/sndstat.c,v 1.29.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder_volume.c,v 1.7.2.1.2.1 2009/10/25
01:10:29 kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/buffer.c,v 1.38.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/mixer.c,v 1.66.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/ac97_patch.c,v 1.12.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/ac97.c,v 1.75.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/dsp.c,v 1.114.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder_rate.c,v 1.29.2.1.2.1 2009/10/25
01:10:29 kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/channel.c,v 1.124.2.1.2.1 2009/10/25 01:10:29
kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder_mixer.c,v 1.1.2.1.2.1 2009/10/25
01:10:29 kensmith Exp $
$FreeBSD: src/sys/dev/sound/pcm/feeder_matrix.c,v 1.1.2.1.2.1 2009/10/25
01:10:29 kensmith Exp $
The relevant part of dmesg:
pcm0: port
0xac00-0xac1f,0xa880-0xa88f,0xa800-0xa80f,0xa480-0xa4bf irq 17 at device
Re: interface for import/export flowtable
On Thu, 22 Jul 2010, alan yang wrote: Hey, Wonder people had implemented interface to import / export flowtable. what exactly do you want to accomplish with that? -- Bjoern A. ZeebFrom August on I will have a life. It's now up to you to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Intel TurboBoost in practice
Hi. I've make small observations of Intel TurboBoost technology under FreeBSD. This technology allows Intel Core i5/i7 CPUs to rise frequency of some cores if other cores are idle and power/thermal conditions permit. CPU core counted as idle, if it has been put into C3 or deeper power state (may reflect ACPI C2/C3 states). So to reach maximal effectiveness, some tuning may be needed. Here is my test case: FreeBSD 9-CURRENT on Core i5 650 CPU, 3.2GHz + 1/2 TurboBoost steps (+133/+266MHz) with boxed cooler at the open air. I was measuring building time of the net/mpd5 from sources, using only one CPU core (cpuset -l 0 time make). Untuned system (hz=1000): 14.15 sec Enabled ACPI C2 (hz=1000+C2): 13.85 sec Enabled ACPI C3 (hz=1000+C3): 13.91 sec Reduced HZ (hz=100): 14.16 sec Enabled ACPI C2 (hz=100+C2): 13.85 sec Enabled ACPI C3 (hz=100+C3): 13.86 sec Timers tuned* (hz=100): 14.10 sec Enabled ACPI C2 (hz=100+C2): 13.71 sec Enabled ACPI C3 (hz=100+C3): 13.73 sec All numbers tested few times and are repeatable up to +/-0.01sec. *) Timers were tuned to reduce interrupt rates and respectively increase idle cores sleep time. These lines were added to loader.conf: sysctl kern.eventtimer.timer1=i8254 sysctl kern.eventtimer.timer2=NONE kern.eventtimer.singlemul=1 kern.hz="100" PS: In this case benefit is small, but it is the least that can be achieved, depending on CPU model. Some models allow frequency to be risen by up to 6 steps (+798MHz). PPS: I expect even better effect achieved by further reducing interrupt rates on idle CPUs. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Intel TurboBoost in practice
2010/7/24 Alexander Motin > Hi. > > I've make small observations of Intel TurboBoost technology under > FreeBSD. This technology allows Intel Core i5/i7 CPUs to rise frequency > of some cores if other cores are idle and power/thermal conditions > permit. CPU core counted as idle, if it has been put into C3 or deeper > power state (may reflect ACPI C2/C3 states). So to reach maximal > effectiveness, some tuning may be needed. > > [snip] > > PPS: I expect even better effect achieved by further reducing interrupt > rates on idle CPUs. > > I'm currently testing a patch that eliminates another 31% of the global TLB shootdowns for a "buildworld" on an amd64 machine. So, you can expect improvement in this area. Alan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Intel TurboBoost in practice
On 24 Jul 2010, at 14:53, Alexander Motin wrote: > Hi. > > I've make small observations of Intel TurboBoost technology under > FreeBSD. This technology allows Intel Core i5/i7 CPUs to rise frequency > of some cores if other cores are idle and power/thermal conditions > permit. CPU core counted as idle, if it has been put into C3 or deeper > power state (may reflect ACPI C2/C3 states). So to reach maximal > effectiveness, some tuning may be needed. > > Here is my test case: FreeBSD 9-CURRENT on Core i5 650 CPU, 3.2GHz + 1/2 > TurboBoost steps (+133/+266MHz) with boxed cooler at the open air. I was > measuring building time of the net/mpd5 from sources, using only one CPU > core (cpuset -l 0 time make). > > Untuned system (hz=1000): 14.15 sec > Enabled ACPI C2 (hz=1000+C2): 13.85 sec > Enabled ACPI C3 (hz=1000+C3): 13.91 sec > Reduced HZ (hz=100): 14.16 sec > Enabled ACPI C2 (hz=100+C2): 13.85 sec > Enabled ACPI C3 (hz=100+C3): 13.86 sec > Timers tuned* (hz=100): 14.10 sec > Enabled ACPI C2 (hz=100+C2): 13.71 sec > Enabled ACPI C3 (hz=100+C3): 13.73 sec > > All numbers tested few times and are repeatable up to +/-0.01sec. > > *) Timers were tuned to reduce interrupt rates and respectively increase > idle cores sleep time. These lines were added to loader.conf: > sysctl kern.eventtimer.timer1=i8254 > sysctl kern.eventtimer.timer2=NONE > kern.eventtimer.singlemul=1 > kern.hz="100" > > PS: In this case benefit is small, but it is the least that can be > achieved, depending on CPU model. Some models allow frequency to be > risen by up to 6 steps (+798MHz). The numbers that you are showing doesn't show much difference. Have you tried buildworld? > > PPS: I expect even better effect achieved by further reducing interrupt > rates on idle CPUs. > > -- > Alexander Motin > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > > > Use the link below to report this message as spam. > https://lavabit.com/apps/teacher?sig=1225540&key=3283483970 > Regards, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Intel TurboBoost in practice
On Sat, Jul 24, 2010 at 9:18 AM, Rui Paulo wrote: > > On 24 Jul 2010, at 14:53, Alexander Motin wrote: > >> Hi. >> >> I've make small observations of Intel TurboBoost technology under >> FreeBSD. This technology allows Intel Core i5/i7 CPUs to rise frequency >> of some cores if other cores are idle and power/thermal conditions >> permit. CPU core counted as idle, if it has been put into C3 or deeper >> power state (may reflect ACPI C2/C3 states). So to reach maximal >> effectiveness, some tuning may be needed. >> >> Here is my test case: FreeBSD 9-CURRENT on Core i5 650 CPU, 3.2GHz + 1/2 >> TurboBoost steps (+133/+266MHz) with boxed cooler at the open air. I was >> measuring building time of the net/mpd5 from sources, using only one CPU >> core (cpuset -l 0 time make). >> >> Untuned system (hz=1000): 14.15 sec >> Enabled ACPI C2 (hz=1000+C2): 13.85 sec >> Enabled ACPI C3 (hz=1000+C3): 13.91 sec >> Reduced HZ (hz=100): 14.16 sec >> Enabled ACPI C2 (hz=100+C2): 13.85 sec >> Enabled ACPI C3 (hz=100+C3): 13.86 sec >> Timers tuned* (hz=100): 14.10 sec >> Enabled ACPI C2 (hz=100+C2): 13.71 sec >> Enabled ACPI C3 (hz=100+C3): 13.73 sec >> >> All numbers tested few times and are repeatable up to +/-0.01sec. >> >> *) Timers were tuned to reduce interrupt rates and respectively increase >> idle cores sleep time. These lines were added to loader.conf: >> sysctl kern.eventtimer.timer1=i8254 >> sysctl kern.eventtimer.timer2=NONE >> kern.eventtimer.singlemul=1 >> kern.hz="100" >> >> PS: In this case benefit is small, but it is the least that can be >> achieved, depending on CPU model. Some models allow frequency to be >> risen by up to 6 steps (+798MHz). > > The numbers that you are showing doesn't show much difference. Have you tried > buildworld? Agreed. The numbers are small enough that there could be a large degree of variation just based on environmental factors alone; there are other things that go into that as well, such as disk I/O, etc, that probably shouldn't be factored into a CPU performance test. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
pageout question
There is a good deal of comments in the vm_pageout.c code that imply that we use
a hysteresis approach to deal with low available pages condition.
Evidence 1:
/*
* v_free_target and v_cache_min control pageout hysteresis. Note
* that these are more a measure of the VM cache queue hysteresis
* then the VM free queue. Specifically, v_free_target is the
* high water mark (free+cache pages).
*
* v_free_reserved + v_cache_min (mostly means v_cache_min) is the
* low water mark, while v_free_min is the stop. [...]
Evidence 2:
/*
* [...] Do
* not clear vm_pages_needed until we reach our target,
* otherwise we may be woken up over and over again and
* waste a lot of cpu.
*/
In general, the hysteresis, the comments and the code make sense.
My doubt, though, is about the block of code that is right below the comment
quoted above:
if (vm_pages_needed && !vm_page_count_min()) {
if (!vm_paging_needed())
vm_pages_needed = 0;
wakeup(&cnt.v_free_count);
}
If I read this code correctly, pagedaemon would go idle as soon as
vm_paging_needed() becomes false. Given the defintion of vm_paging_needed as
(v_free_reserved + v_cache_min) > (v_free_count + v_cache_count)
this means that pagedaemon quits paging as soon as available page count is above
_low_ watermark. Which contradicts the comments and the general logic of the
code. (Paging also generally starts only when vm_paging_needed() is true).
I think that it also means that vm_pageout_scan is called with pass > 0 only in
very very low memory conditions, where the first pass (pass=0) wasn't able to
free up memory even above low watermark.
But my impression is that the intention was to keep pagedaemon working until
high watermark was reached (vm_paging_target() < 0). Plus, perhaps, some more
depending on vm_pageout_deficit.
And, yes, I see that vm_pageout_scan() has a goal of reaching vm_paging_target()
+ vm_pageout_deficit, but I am speaking of the case where it is unable to do so
on the first pass.
Do I misunderstand something?
Is there a flaw in the code or are the comments
outdated/misleading/not-descriptive-enough?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Intel TurboBoost in practice
Hi mav. On Sat, 24 Jul 2010 16:53:10 +0300 Alexander Motin wrote: > PS: In this case benefit is small, but it is the least that can be > achieved, depending on CPU model. Some models allow frequency to be > risen by up to 6 steps (+798MHz). I tested on Core i7 640UM (Arrandale 1.2GHz -> 2.26GHz) with openssl speed (w/o aesni(4)) and /usr/src/tools/tools/crypto/cryptotest.c (w/ aesni(4)). http://people.freebsd.org/~nork/aesni/aes128cbc-noaesni.pdf [1] http://people.freebsd.org/~nork/aesni/aes128cbc-aesni.pdf [2] [1] $ /usr/bin/cpuset -l$i /usr/bin/openssl speed -elapsed -mr -multi $n aes128-cbc $i = 0 1 2 3 0,1 0,2 0,3 1,2 1,3 2,3 0,1,2 0,1,3 0,2,3 1,2,3 0,1,2,3 $n = numbers of core, $((`echo $i | wc -c`/2)) [2] $ /usr/bin/cpuset -l$i ./cryptotest -t $n -z 5 8192 $i = 0 1 2 3 0,1 0,2 0,3 1,2 1,3 2,3 0,1,2 0,1,3 0,2,3 1,2,3 0,1,2,3 $n = numbers of core, $((`echo $i | wc -c`/2)) In my environment, according to aes128cbc-noaesni.pdf, at least, 30% performace up by Turbo Boost (I think). And according to aes128cbc-aesni.pdf, at least, 100% performance up by Turbo Boost (I think). And I understand reducing single thread performance by Hyper Threading:-). -- Norikatsu Shigemura ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Intel TurboBoost in practice
Norikatsu Shigemura wrote: > On Sat, 24 Jul 2010 16:53:10 +0300 > Alexander Motin wrote: >> PS: In this case benefit is small, but it is the least that can be >> achieved, depending on CPU model. Some models allow frequency to be >> risen by up to 6 steps (+798MHz). > > I tested on Core i7 640UM (Arrandale 1.2GHz -> 2.26GHz) with > openssl speed (w/o aesni(4)) and > /usr/src/tools/tools/crypto/cryptotest.c (w/ aesni(4)). > > http://people.freebsd.org/~nork/aesni/aes128cbc-noaesni.pdf [1] > http://people.freebsd.org/~nork/aesni/aes128cbc-aesni.pdf [2] > > In my environment, according to aes128cbc-noaesni.pdf, at least, > 30% performace up by Turbo Boost (I think). The numbers are interesting, though they are not proving much, because of many other factors may influence on result. It would be more informative to do the tests with C1 and C2/C3 states used. > And according to aes128cbc-aesni.pdf, at least, 100% performance > up by Turbo Boost (I think). This IMHO is even more questionable. Single, even boosted core shouldn't be faster then 2, 3 and 4. I would say there is some scalability problem. May be context switches, locking, or something else. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Intel TurboBoost in practice
Rui Paulo wrote: > On 24 Jul 2010, at 14:53, Alexander Motin wrote: >> Here is my test case: FreeBSD 9-CURRENT on Core i5 650 CPU, 3.2GHz + 1/2 >> TurboBoost steps (+133/+266MHz) with boxed cooler at the open air. I was >> measuring building time of the net/mpd5 from sources, using only one CPU >> core (cpuset -l 0 time make). >> >> Untuned system (hz=1000): 14.15 sec >> Enabled ACPI C2 (hz=1000+C2): 13.85 sec >> Enabled ACPI C3 (hz=1000+C3): 13.91 sec >> Reduced HZ (hz=100): 14.16 sec >> Enabled ACPI C2 (hz=100+C2): 13.85 sec >> Enabled ACPI C3 (hz=100+C3): 13.86 sec >> Timers tuned* (hz=100): 14.10 sec >> Enabled ACPI C2 (hz=100+C2): 13.71 sec >> Enabled ACPI C3 (hz=100+C3): 13.73 sec >> >> All numbers tested few times and are repeatable up to +/-0.01sec. >> >> PS: In this case benefit is small, but it is the least that can be >> achieved, depending on CPU model. Some models allow frequency to be >> risen by up to 6 steps (+798MHz). > > The numbers that you are showing doesn't show much difference. Have you tried > buildworld? If you mean relative difference -- as I have told, it's mostly because of my CPU. It's maximal boost is 266MHz (8.3%), but 133MHz of them is enabled most of time if CPU is not overheated. It probably doesn't, as it works on clear table under air conditioner. So maximal effect I can expect on is 4.2%. In such situation 2.8% probably not so bad to illustrate that feature works and there is space for further improvements. If I had Core i5-750S I would expect 33% boost. If you mean absolute difference, here are results or four buildworld runs: hw.acpi.cpu.cx_lowest=C1: 4654.23 sec hw.acpi.cpu.cx_lowest=C2: 4556.37 sec hw.acpi.cpu.cx_lowest=C2: 4570.85 sec hw.acpi.cpu.cx_lowest=C1: 4679.83 sec Benefit is about 2.1%. Each time results were erased and sources pre-cached into RAM. Storage was SSD, so disk should not be an issue. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pageout question
On Sat, 24 Jul 2010 23:23:07 +0300
Andriy Gapon wrote:
>
> There is a good deal of comments in the vm_pageout.c code that imply
> that we use a hysteresis approach to deal with low available pages
> condition.
>
>
> In general, the hysteresis, the comments and the code make sense.
> My doubt, though, is about the block of code that is right below the
> comment quoted above:
> if (vm_pages_needed && !vm_page_count_min()) {
> if (!vm_paging_needed())
> vm_pages_needed = 0;
> wakeup(&cnt.v_free_count);
> }
As I understand it the hysteresis is done inside vm_pageout_scan, and
the expectation is that one pass will typically satisfy this because the
design aims to keep enough clean pages in the inactive queue.
I'm not sure if the vm_paging_needed() call is correct or not, but it
may be that that the intent is to avoid immediately going back to a
depleted inactive queue when cache+free is within normal bounds,
because it could result in avoidable paging to swap.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
