[Cbe-oss-dev] [RFC,PATCH] libspe2: stop using spe_fds_refcount

Kazunori Asayama asayama at sm.sony.co.jp
Wed Dec 6 23:04:56 EST 2006

Dirk Herrendoerfer <d.herrendoerfer at de.ibm.com> wrote:
> Kazunori Asayama <asayama at sm.sony.co.jp> wrote on 06.12.2006 11:45:31:
> > I'd like to raise again an issue about use of reference counters
> > for file descriptors (spe_fd_refcount) in libspe2/spebase.
> I'm  aware of the issue that the code is almost useless right now, but
> sine every linux process is limited to 1024 open files I see a need for
> the ability to close event source files.
> Right now there is no need for it, but when the preemptive scheduling
> becomes available and processes start making use of more spes, and use
> the files without closing them we will run out of file descriptors at about
> 64 spe threads.
> I would propose to leave the code as ist is and close files that are not
> used as frequently - the signal1&2 file for example.
> > I propose to stop using spe_fds_refcount because of the following
> > reasons:
> >
> >   1. That mechanism does not work well currently.
> >
> >      None decrements the counters incremented by mbox functions. That
> >      means that the current implementation of the mechanism is almost
> >      meaningless.
> Yes, I see no reason to close files that should be accessible always and
> quickly, but I'd like to close those that are only needed seldomly.
> In any case all files are closed when the spe context is disposed of.
> >   2. Even if the problem 1. is solved, performance issues will appear.
> >
> >      That is, mbox and/or SNR functions will become to close and to
> >      re-open the FDs frequently. It seems quite inefficient.
> See above, but the small performance loss for couting the number of users
> is still better than stalling or crashing if the app runs out of
> filedescriptors.
> > What do you think ?
> >
> Hope this sheds some light on the intent of the function.

OK. I understand and agreed.

(ASAYAMA Kazunori
  (asayama at sm.sony.co.jp))

More information about the cbe-oss-dev mailing list