Re: [Linux-kernel-mentees] [v10 3/4] media: vidtv: add a bridge driver

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Hi Geert,

Em Tue, 15 Sep 2020 15:35:00 +0200
Geert Uytterhoeven <geert@linux-m68k.org> escreveu:

> Hi Daniel,
> 
> On Tue, Sep 15, 2020 at 3:26 PM Daniel W. S. Almeida
> <dwlsalmeida@gmail.com> wrote:
> > >> +    u32 nbytes = 0;  /* the number of bytes written by this function */
> > >> +
> > >> +    u64 nbytes_expected; /* the number of bytes we should have written */
> > >> +    u64 nbytes_streamed; /* the number of bytes we actually wrote */
> > >> +    u32 num_null_pkts; /* number of null packets to bridge the gap */
> > >> +
> > >> +    u64 elapsed_time_msecs = jiffies_to_usecs(m->timing.current_jiffies -
> > >> +                                              m->timing.past_jiffies);
> > >> +
> > >> +    elapsed_time_msecs = min(elapsed_time_msecs,
> > >> (u64)VIDTV_MAX_SLEEP_USECS / 1000);
> > >> +    nbytes_expected = div64_u64(m->mux_rate_kbytes_sec * 1000, MSEC_PER_SEC);  
> > >
> > > Seriously?!?
> > >
> > > You multiply by 1000 first, followed by a division by 1000 using an
> > > expensive 64-by-64 division?  
> >
> > This entire function is broken and needs a do-over :)
> >  
> > > using an expensive 64-by-64 division?  
> >
> > I am new to kernel development. I wasn't even aware that this was
> > expensive, to be honest.  
> 
> All divisions involving 64-bit data are expensive, especially on 32-bit
> platforms.  That's why we have the helpers in <linux/math.h>.  Most
> of them implement simplified variants, which are less expensive.

I agree that 64-bit math is something that should be used with some
care. However, it is almost unavoidable do to 64-bit divisions for
digital TV.

See, digital TV system deals with frequencies that go up to
2,150 GHz (and that's after converting them from ~10 GHz range,
which is done on userspace, on satellite systems).

Basically, most DVB drivers end using 64 bits math to setup clocks.
Although we converted most of those cases - I guess there are still
a few legacy drivers (written before 64bit archs) that use an
algorithm for 64 bits division with a 32 bits result. That should
be more expensive than a 64-bits division, specially on 64-bit archs.

Also, stream bit rates are at the order of up to 50 Mbits/s. So,
QoS stats usually need to do 64-bit math too, in order to avoid
overflows.

-

On the other hand, a few 64-bits math operations at Kernel side
means nothing in terms of the systems performance, as those are usually 
done  either at setup phase or when some data packets arrived. Most
of CPU cycles ended being spent at MPEG-TS decoding and at audio/video
codecs, with needs to be done for each sample, and usually spend
lots of CPU (and GPU) cycles doing math and copying big chunks of
data.

Thanks,
Mauro
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees