I experienced a power loss and upon booting of the system, fsck was run on
my / partition (ext3). When it was done i noticed the following;
zwane@montezuma:~ $ cat /proc/version
Linux version 2.4.13-ac5-preempt ([email protected]) (gcc version
2.96 20000731 (Red Hat Linux 7.1 2.96-81)) #1 Wed Oct 31 19:55:49 SAST
2001
zwane@montezuma:~ $ cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 525602816 243605504 281997312 552960 145076224
18446744073614016512
Swap: 139788288 0 139788288
MemTotal: 513284 kB
MemFree: 275388 kB
MemShared: 540 kB
Buffers: 141676 kB
Cached: 4294874000 kB
SwapCached: 0 kB
Active: 188024 kB
Inact_dirty: 2032 kB
Inact_clean: 0 kB
Inact_target: 104852 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 513284 kB
LowFree: 275388 kB
SwapTotal: 136512 kB
SwapFree: 136512 kB
System still ran fine like this, but when i opened a 100Mb avi with
mplayer the disk cache dropped down to 2megs. There now seems to be a
slight discrepancy with regards to how ram is allocated, i just started X
but i seem to have more memory under used/shared in xosview than normal
(~100megs discrepancy)
zwane@montezuma:~ $ cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 525602816 417894400 107708416 1089536 155455488 3702784
Swap: 139788288 0 139788288
MemTotal: 513284 kB
MemFree: 105184 kB
MemShared: 1064 kB
Buffers: 151812 kB
Cached: 3616 kB
SwapCached: 0 kB
Active: 192816 kB
Inact_dirty: 114424 kB
Inact_clean: 0 kB
Inact_target: 104852 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 513284 kB
LowFree: 105184 kB
SwapTotal: 136512 kB
SwapFree: 136512 kB
On Sat, 2001-11-03 at 04:51, Zwane Mwaikambo wrote:
> I experienced a power loss and upon booting of the system, fsck was run on
> my / partition (ext3). When it was done i noticed the following;
ac7 contains a fix for cache memory accounting; I think it would fix
your problem. can you give it a try? the preempt patch for ac6 should
apply fine...
Robert Love
On 5 Nov 2001, Robert Love wrote:
> On Sat, 2001-11-03 at 04:51, Zwane Mwaikambo wrote:
> > I experienced a power loss and upon booting of the system, fsck was run on
> > my / partition (ext3). When it was done i noticed the following;
>
> ac7 contains a fix for cache memory accounting; I think it would fix
> your problem. can you give it a try? the preempt patch for ac6 should
> apply fine...
>
> Robert Love
>
Thanks, I just saw a thread discussing the very same issue i had, i'll
download both ac7 and the ac6 preempt patch and give it a try.
PS I know you keep hearing this, but that preempt patch makes for some
damn smooth interactive performance ;)
Regards,
Zwane Mwaikambo
On Mon, 2001-11-05 at 03:21, Zwane Mwaikambo wrote:
> Thanks, I just saw a thread discussing the very same issue i had, i'll
> download both ac7 and the ac6 preempt patch and give it a try.
Please let me know.. I've had a few reports and I want to consider this
bug fixed -- and not even our fault: the best kind.
I went ahead and rediffed the patch against 2.4.13-ac7, the -ac6 will
apply fine. For future use however, it will be up at
ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/
soon as the it syncs.
> PS I know you keep hearing this, but that preempt patch makes for some
> damn smooth interactive performance ;)
I can't hear it enough :)
Robert Love
Robert Love wrote:
>
> > PS I know you keep hearing this, but that preempt patch makes for some
> > damn smooth interactive performance ;)
>
> I can't hear it enough :)
>
umm... Look. Sorry. But I don't see any theoretical reason
why interactivity should be noticeably different from the
little patch at
http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.14pre7aa2/00_lowlatency-fixes-2
and I did some quantitative testing a week or so back which
bears this out. With either patch, worst-case latencies
are very rare, and very bad. Usual latencies are excellent.
Is there any reason why preempt should be noticeably better than
that little patch? If it is, then where on earth are the
problematic commonly-occuring, long-running, lock-free code paths?
-
On Mon, 5 Nov 2001, Andrew Morton wrote:
> Robert Love wrote:
> >
> > > PS I know you keep hearing this, but that preempt patch makes for some
> > > damn smooth interactive performance ;)
> >
> > I can't hear it enough :)
> >
>
> umm... Look. Sorry. But I don't see any theoretical reason
> why interactivity should be noticeably different from the
> little patch at
>
> http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.14pre7aa2/00_lowlatency-fixes-2
>
> and I did some quantitative testing a week or so back which
> bears this out. With either patch, worst-case latencies
> are very rare, and very bad. Usual latencies are excellent.
>
> Is there any reason why preempt should be noticeably better than
> that little patch? If it is, then where on earth are the
> problematic commonly-occuring, long-running, lock-free code paths?
Unfortunately i haven't tested that patch so i can't provide an objective
comparison. In which case are there patches for -ac? because if not there
might also be other factors influencing the "perception" of improved
interactivity, this is mainly because i'm doing "tests" by just plain
using the box for an extended period instead of "real" scientific tests.
Regards,
Zwane Mwaikambo
>
> -
>
On Mon, Nov 05, 2001 at 12:37:55AM -0800, Andrew Morton wrote:
> Robert Love wrote:
> >
> > > PS I know you keep hearing this, but that preempt patch makes for some
> > > damn smooth interactive performance ;)
> >
> > I can't hear it enough :)
> >
>
> umm... Look. Sorry. But I don't see any theoretical reason
> why interactivity should be noticeably different from the
> little patch at
>
> http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.14pre7aa2/00_lowlatency-fixes-2
indeed, the only thing that PE can really change is the mean latency but
everbody only cares about worst case latency and nominal performance,
possibly except realtime signal processing (not multimedia playback
like listening mp3).
Andrea