Am Sonntag, 13. MÃrz 2005 14:44 schrieben Sie:
> That seems very much like expected behavior to me. I would expect kwrite
> to start loading the file, and then having pdflush kick in to page out
> parts of kwrite, so that it can allocate more memory. Then kwrite will
> continue to load until more of it needs to be paged out, at which point
> pdflush will engage again, and so on, until the file is loaded.
Well not quite. kwrite uses not so much ram. And I have 1Gig:
[EMAIL PROTECTED]:/files/ipt$ cat gross > /dev/null
[EMAIL PROTECTED]:/files/ipt$ free
total used free shared buffers cached
Mem: 1032592 507564 525028 0 868 336072
-/+ buffers/cache: 170624 861968
Swap: 498920 0 498920
[EMAIL PROTECTED]:/files/ipt$ kwrite gross
[1]+ Stopped kwrite gross
# kwrite loaded completely
[EMAIL PROTECTED]:/files/ipt$ free
total used free shared buffers cached
Mem: 1032592 848900 183692 0 876 651632
-/+ buffers/cache: 196392 836200
Swap: 498920 0 498920
Acording to top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ CODE DATA COMMAND
18436 alex 16 0 44476 29m 14m S 0.0 2.9 0:11.04 4 13m kwrite
> Of course, I don't know if you may have a gig or so of RAM, but I'm
> having trouble believing that a 150 MB file could be kept in cache,
> especially given that kwrite allocates at least as much anonymous memory
> to hold it internally.
Is there any whay I can be sure a file is cached? cat file > /dev/null takes
130ms, that should be ok?
> Now, I can't really speak for reiser4, but it doesn't seem too
> incredible that it would be flushing page usage or rebalancing some tree
> or something like that. As long as it is niced down (I dunno if it
> actually is, though...), that shouldn't be a problem.
Well, It's not niced down, and it was doing what so ever while reading, not
while writing?
regards
Alex
> > regards
> > Alex
> >
> > Am Donnerstag, 10. MÃrz 2005 15:22 schrieb E.Gryaznova:
> > > I opened 190Mb textfile with kwrite and tried to do "goto line
> > > number 1 800 000" (file has about 6 000 000 lines). File is placed not
> > > on reiser4 but on ext2 partition. And I see that kwrite eats about
> > > 90-100% CPU.
> > > Does kwrite work fine for you on so big files on ext2 filesystem?
> > >
> > > I have the following kde version:
> > > [EMAIL PROTECTED]:~> kwrite --version
> > > Qt: 3.2.1
> > > KDE: 3.1.4
> > > KWrite: 4.1
> > >
> > > Thanks,
> > > Lena.
> > >
> > > >Begin forwarded message:
> > > >
> > > >Date: Fri, 4 Mar 2005 02:24:36 +0100
> > > >From: Alexander Gran <[EMAIL PROTECTED]>
> > > >To: linux-kernel@vger.kernel.org
> > > >Subject: 2.6.11-rc5-mm1: reiser4 eating cpu time
> > > >
> > > >
> > > >Hi,
> > > >
> > > >I have a reiser4 partition on a local IDE disk. I opened a 130MB
> > > > textfile with kwrite, and killed it while ot opened the file (took to
> > > > long...) diskio was finished at this point.
> > > >a [ent:hda6.] Process was eating 100% CPU time for several (54)
> > > > seconds. Is this a normal, expected behaviour?
> > > >After trying again, pdflush was eating much cpu time, about the same
> > > > (50+ secs) Note that this happend after reiser4 panic (on an external
> > > > disk as reported several minutes ago).
> > > >
> > > >regards
> > > >Alex
--
Encrypted Mails welcome.
PGP-Key at http://zodiac.dnsalias.org/misc/pgpkey.asc | Key-ID: 0x6D7DD291
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
