Message-ID: <a61e3494-1923-3971-c4e2-f32299aa29bc@dpolakovic.space>
Date: Thu, 4 Jul 2024 23:13:16 +0200
From: David Polakovic <email@...lakovic.space>
To: Theodore Ts'o <tytso@....edu>
Cc: Alexander Lobakin <aleksander.lobakin@...el.com>,
 Bagas Sanjaya <bagasdotme@...il.com>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Ingo Molnar <mingo@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 Andrew Morton <akpm@...ux-foundation.org>, "H. Peter Anvin" <hpa@...or.com>,
 Alexander Lobakin <alexandr.lobakin@...el.com>,
 Jakub Kicinski <kuba@...nel.org>
Subject: Re: proposition for fixing Y292B bug

On 7/4/24 19:49, 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.
>
> 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.
>
> 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.
>
> Cheers,
>
> 					- Ted

I appreciate your response, finally some thoughts on the proposition itself
and please let me clear something up. It was exactly as you said, an 
tradeoff
I considered worthy and I wasn't expecting anyone to do "my work".
I thought that someone, experienced enough, might find this worthy
of try.

However, I'll take your challenge, and I will try to do the work on my 
own, if no
one else will. Let's see where it will lead me.

dpo

Powered by blists - more mailing lists