Hi,
Hmmm, this really looks like something in the program is touching the
whole 2 Gbytes of data in there. Can you send us the source code of
your program and how you build it (or at least a test case which
has the same results). Could you also run strace on the program and
send the output. Finally could you run xfs_bmap -v on the output file
and send us the output of that too.
Thanks
Steve Lord
> Dear friends:
> Thanks every much for your kindness, my questions were gradually solved
> here.
>
> Now I can use fseeko64() now, but in fact it takes very long time
> for a fseeko64() call as if the call is suspended. During the call,
> kswapd use CPU madly, statistics as follows:
>
> 2:30pm up 3:17, 4 users, load average: 0.23, 0.05, 0.02
> 45 processes: 41 sleeping, 4 running, 0 zombie, 0 stopped
> CPU states: 1.9% user, 98.0% system, 0.0% nice, 0.0% idle
> Mem: 126104K av, 123992K used, 2112K free, 0K shrd, 6780K buff
> Swap: 56188K av, 0K used, 56188K free 98704K
> cached
>
> PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
> 3 root 17 0 0 0 0 RW 0 90.0 0.0 3:12 kswapd
> 2112 root 9 0 428 428 304 R 0 6.7 0.3 0:00 a.out
> 2113 root 12 0 872 872 684 R 0 3.8 0.6 0:00 top
> 1 root 8 0 476 476 404 S 0 0.0 0.3 0:05 init
> 2 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 kapmd
> 4 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 kflushd
> 5 root 9 0 0 0 0 SW 0 0.0 0.0 0:03 kupdate
> 6 root -1 -20 0 0 0 SW< 0 0.0 0.0 0:00 mdrecoveryd
> 19 root 9 0 548 548 452 S 0 0.0 0.4 0:00 devfsd
> 1028 root 9 0 0 0 0 SW 0 0.0 0.0 0:00
> pagebuf_daemon
> 1029 root 9 0 0 0 0 SW 0 0.0 0.0 0:00 page_daemon
> 1291 bin 9 0 496 496 404 S 0 0.0 0.3 0:00 portmap
> 1291 bin 9 0 496 496 404 S 0 0.0 0.3 0:00 portmap
> 1314 root 9 0 560 560 472 S 0 0.0 0.4 0:00 rpc.statd
> 1328 root 9 0 480 480 412 S 0 0.0 0.3 0:00 apmd
> 1384 root 9 0 552 552 452 S 0 0.0 0.4 0:00 syslogd
> 1393 root 9 0 1080 1080 388 S 0 0.0 0.8 0:00 klogd
> 1407 nobody 9 0 628 628 520 S 0 0.0 0.4 0:00 identd
>
> a.out is my test program, which opens a big file(4.7G) on xfs filesystem
> by using fopen64(); and then use fseeko64() to locate to 2.1G. The statistics
> is got when the program executing fseeko64(), it took more than 2 minutes.
> After
> 2 minutes, the call return successfully.
>
> My questions are:
> why it took so many time for a seek call? I'v never met it on ext2 or
> xfs
> on IRIX.
> why kswapd ate all my CPU resource and memory resource when I call
> fseeko64()?
>
> My destination is to use big files in my program, open/read/seek, very
> simple
> needs, but how can I do this?
>
> Thanks a lot!
> yangxy.
|