From: Keith Owens <kaos@sg...> - 2005-02-12 23:43:37
On Sat, 12 Feb 2005 10:31:45 +0100,
"philippe benard" <phi.benard@...> wrote:
>Can't we make the assumption that such gigantic physmem are MP as well, then
>devoting some gziping some proc while 1 proc handle the polling io?
I wish that we could, but we are up against the IA64 SAL specification.
For an MCA event, the SAL spec requires that all but one processor is
effectively disabled, they are spinning in SAL code. For an IA64 MCA
you only get one workable cpu.
From: Keith Owens <kaos@sg...> - 2005-02-13 04:24:44
On Sat, 12 Feb 2005 19:37:34 -0800,
Jason Uhlenkott <jasonuhl@...> wrote:
>On Sat, Feb 12, 2005 at 10:31:45AM +0100, philippe benard wrote:
>> Hi All,
>> Can't we make the assumption that such gigantic physmem are MP as well,
>> then devoting some gziping some proc while 1 proc handle the polling io?
>As Keith pointed out, that's problematic on ia64 at least.
>It might be possible to have the dumping cpu itself do some useful
>work while waiting for I/O, though. We'd just need the compression
>code to register a function somewhere that we can call from the loop
>after we fire off a request while we wait for it to complete.
That requires a major redesign of the compression and I/O code paths.
At the very least it needs a separate buffer to compress into while you
are waiting for the I/O of the previous buffer to complete.
To get any decent overlap, the compression code and the polling mode
I/O loop have to function as coroutines. Each gets called to do some
work, does a bit then yields the cpu to let other work continue.
I had this working nicely in dumpfs, which was an attempt to completely
separate the RAS data capture from the compression and I/O. Some day I
may have time to get back to dumpfs.
Get latest updates about Open Source Projects, Conferences and News.