Re: Tzw. "uzycie pliku stron"...

Paweł Goleń napisał(a):
> No nie do końca mogę się z Tobą zgodzić Radku (a znaczna część posta

Ależ Ty nie tylko się ze mną zgodziłeś, ale nawet
potwierdziłeś i rozszerzyłeś nieco ten wątek :)

> jest odpowiedzią dla pytającego). Po części masz rację, ale prawda jest
> taka, że 99% ze standardowych wartości WorkingSet. Ładnie pokazuje to na
> przykład wspominany już debugger dla Windows. Wartości graniczne
> WorkingSet nie są bynajmniej sztywne, dla przykładu Thunderbird:

Oczywiście, że nie są sztywne. Dopóki proces nie wymusi
zwolnienia zestawu roboczego lub inna aplikacja nie
zgłosi zapotrzebowania na pamięć, zestaw roboczy może
przekroczyć w górę narzucony limit.

> Jak widzisz obecna wartość Working Set znacznie przekracza wartość max.
> Natomiast gdy zminimalizuję Thunderbirda:

I to widzisz "błąd" mający swoje źródło jeszcze w
pierwszych wersjach NT -- minimalizacja okna powoduje
automatycznie żądanie zwolnienia zestawu roboczego.
Kiedyś to pozwalało wcisnąć więcej procesów na maszynach
z 8 i 16 MiB pamięci, dzisiaj powoduje silne swapowanie
gdy po chwili pracy w innym programie usiłujesz przyw-
rócić na ekran zminimalizowane okno.

> Nie oznacza to jednak, że te 20MiB pamięci było wczytywane z dysku.

Oczywiście, że nie! NT nie wywala zwalnianych stron
do pliku wymiany *natychmiast*, lecz odkłada "na bok"
w nadziei, że jeszcze za chwilę mogą być potrzebne.
Dopiero, gdy inne zadania (lub choćby sam file cache!)
będą potrzebowały coraz więcej RAMu, ta pula zapasowa
zostanie wymieciona do pliku wymiany. Spróbuj zminimali-
zować Thunderbirda, odpalić program alokujący np. 1/3
RAMu na chwilę, zamknąć go i przywrócić Thunderbirda --
podejrzewam, że będzie swapował ostro w tym momencie.

> Jeśli żadna inna aplikacja nie poprosiła o pamięć i system nie
> przydzielił jej tych stron, które były wykorzystywane przez
> Thunderbirda, proces dostanie swoje "stare" strony. W przeciwnym
> przypadku system musiałby wczytać stosowne strony z pliku wymiany.

No właśnie. PS. Niekoniecznie z pliku wymiany, ale
być może też z EXEca i zmapowanych w pamięci plików.
Silna fragmentacja spowalnia swapowanie. Kiedyś może
przydałoby się, by wymiana obejmowała nie strony 4 KiB,
ale większe bloki, na przykład po 64 KiB?

> A teraz popatrzmy na linuksa. System nie używa swap do czasu, do kiedy
> ma pamięć. Powiedzmy, że jest wydajniej (powiedzmy, bo pamiętaj o tym co

A to zależy od parametru 'swappiness' ustalanego
dowolnie przez użytkownika. Możesz wymusić zacho-
wanie zbliżone do Windows lub silnie ograniczyć
systemowi wykorzystanie pliku wymiany.

> pisałem o odzyskiwaniu pamięci z listy Standby). W pewnej chwili kończy
> się pamięć i... i system musi skorzystać z pliku wymiany. W efekcie
> następuje mocne swappowanie, które zbiega się z uruchamianiem programu,
> może wówczas powstać dość spore obciążenie I/O, bo linuks stara się w

Pytanie tylko czy w obecnych czasach, gdy komputery
mają pamięci "od cholery", lepsze jest działanie
asekuracyjne w stylu Windows dające w efekcie często
intensywne (przy dużych aplikacjach) swapowanie mimo
dostępności pamięci, czy ewentualne jeszcze silniejsze
swapowanie w sytuacjach krytycznych przy braku swapo-
wania w czasie normalnej pracy (kosztem nawet nieco
mniejszego cache plików).

Ja na swoim desktopie w Linuksie ustawilem swappiness
na minimalną wartość, by dopiero w ostateczności swapo-
wał. Z 512 MiB RAMu rzadko wykorzystuję ponad 300 MiB,
więc w efekcie tylko bardzo intensywna praca powoduje
sięgnięcie po swap.

> Reasumując, nie jest prawdą, że Windows nie potrafi wykorzystać w pełni
> dostępnej pamięci. To, co widzisz jako free tak na prawdę wcale free nie

Oczywiście, że potrafi -- tylko robi to z innymi priorytetami,
niż życzyliby sobie użytkownicy mimo wszystko. Chętnie bym
widział w Windows możliwość np. odgórnego ograniczenia roz-
miaru cache plików (niektóre procesy zbytnio je nadymają --
są to błędy procesów oczywiście, vide
http://www.grush.one.pl/article.php?id=fileflags,
jednak warto by z tym odgórnie walczyć ustawieniami systemo-
wymi).

-- 
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  mailto:rsokol@magsoft.com.pl          |
|                 |  http://www.grush.one.pl/              |
\................... ftp://ftp.grush.one.pl/ ............../