[FFmpeg-devel] [PATCH] NellyMoser audio decoder

Michael Niedermayer michaelni
Wed Sep 12 02:43:10 CEST 2007


Hi

On Tue, Sep 11, 2007 at 08:02:32PM -0400, Rich Felker wrote:
> On Wed, Sep 12, 2007 at 01:30:22AM +0200, Michael Niedermayer wrote:
> > Hi
> > 
> > On Tue, Sep 11, 2007 at 07:19:48PM -0400, Compn wrote:
> > > what is the name of this bikeshed?
> > 
> > runtime generation of tables vs. hardcoding them in the object file
> > 
> > the argument that the kernel can find such tables quickly even if 
> > generated at runtime and share them with a copy on write hasnt been
> > brought up yet :)
> 
> I don't want a kernel process hashing and comparing pages while I'm
> trying to watch a movie to determine which ones it can combine... The
> extra bookkeeping is just a bad idea.

you prefer if it pages things out to disk while you watch a movie? because
that together with the OOM killer is the alternative if you are out of
memory, if you arent (close to being) out of memory then there is no need
for the kernel to go hashing pages aggressively

also the kernel has to keep track of which pages have been accessed recently
anyway to be able to make a sane decission on what to page out, or it has a
good chance that the paged out page has to be paged in almost immedeatly

now if it does keep track of what has not been accessed recently it can as
well keep track of what has not been written to recently and just hash pages
which didnt change, if you hash just pages which didnt change in the last hour
you also wont hash anyhing more often then once per hour though in practice
it would be significantly less as things which didnt change in an hour likely
wont soon ...

another interresting idea would be to compress pages instead of paging them
out but i guess this is getting a little off topic ...

also the hashing and comparing could very well be done by a manualy run tool
so it would never happen in the background ...


> 
> > (no i dont know of any such kernel but its possible in principle and would
> > render shared libs even less usefull then they already are which would be a
> > good thing)
> 
> Nope, it won't. Modules from static libs will not be in the same
> page-boundary-relative locations in different binaries; moreover, only
> the needed .o files will be included, and they'll each be patched with
> different relocations. I don't see any way this could work..

it can work if big things are aligned relative to pages ...

and about relocations, i think there would be plenty of pages which contain
none ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070912/145baa5d/attachment.pgp>



More information about the ffmpeg-devel mailing list