Re: proposition for fixing Y292B bug

[Bagas Sanjaya <bagasdotme@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]

On Thu, Jul 04, 2024 at 01:49:17PM -0400, Theodore Ts'o wrote:
> On Wed, Jul 03, 2024 at 05:29:58PM +0200, David Polakovic wrote:
> > 
> > I am not sure if I don't understand your solution, but extending the
> > memory designation from 64 to 128 bits, is another temporary
> > solution, which will again overflow one day.
> > 
> > The sole reason why I was proposing the new "BigInt" type was to
> > store each digit of the time_c as separate element of array, which
> > could be resized (added one digit) as needed. The only limit would
> > then be the physical amount of memory in the machine.
> 
> You state that you're not experienced enough to be able to send "a
> merge request".  Fair enough; you also apparently don't know that
> github merges is not how kernel patches are submitted, reviewed, and
> integrated.

tl;dr: Documentation/process/submitting-patches.rst.

> 
> What you apparently don't appreciate it is that performance is
> something that is critically important for the Linux kernel, and using
> multiple precision integers is not really compatible with the best and
> highest performance.  Computer Science is an engineering discipline,
> and it's all about tradeoffs.  You could enginere a plane that can
> travel faster than the speed of sound, but if that compromises fuel
> efficiency and annoying people who are below its flight path, pursuing
> speed at all costs is not going to lead to commercial success.
> (Exhibit 1: The Concorde).
> 
> Similarly, trying to make sure that software will work in the year 292
> Billion AD might not be all something that most people would consider
> high priority.  After all, it's.... unlikely... that the x86_64
> architecture will still be what we will be using 290 billion years
> from now.  So if we need recompile the kernel sometime in the next 100
> billion years for some new CPU architecture, and if it's unlikely that
> hard drives brought brand new are likely to be still in operation a
> decade or two from now --- there is plenty of time to evolve the
> on-disk format before a billion years go by, let alone 100 billion or
> 200 billion years.

That was what I thought when I first read this thread (good CS principle
but questionable from engineering perspective).

> 
> Finally, kernel development is driven by people who are willing to do
> the work.  If you want to demonstrate that it's possible to use MP
> integer mathematicswithout horribly comprmising performance, then you
> need to do the work.  (BTW, if you don't know what the term "cache
> line" means, then I encourage that you understand that first.)  But
> dropping a pointer to a blog post and expecting that people to do your
> homework for you is not really realistic.

Oh, I missed that "DIY" nature.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]