From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Sun Aug 12 15:11:53 EDT 2018 Message-ID: Date: Sun, 12 Aug 2018 21:11:45 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org Subject: Re: [9front] time In-Reply-To: 20180811204436.GA28541@wopr MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: content-addressed singleton scripting ACPI over JSON scripting wrapper blockchain this sucks. burnzez talked to me explaining the lack of resolution of kernel process time accounting but no context has been given in this patch. the issue is the kernel tracks time in user / kernel and realtime for each process. this is exposed in /proc/n/status and the wait() syscall as 32 bit unsigned integers with unit in milliseconds. which gives a maximum resolution of arround 50 days. internally, user/kernel time accounting works by hzclock() just incrementing a per process counter of ticks. which is not very precise and processes can evade time being accounted by yielding so they'd miss the timer interrupt. so there is an opportunity here that when going to 64 bit, we could improve the time accounting and change the unit to nanoseconds as well... there are a bunch of things that can be done, but carefull preparation is needed to not break backwards compatibility. keeping the unit in milliseconds but increasing the bits to 64 bit is trivial for the wait() syscall. as its already parsed as text... and not many programs use wait() and look at the process times. so there should be minimal breakage. for /proc/n/status we have to see... the kernel makes an effort to align all the fields in a fixed format. but ps(1) doesnt really mind and tokenizes the whole thing. so we need to check which programs still rely on the fixed format. as for the patch... no. i dont like it. its a kludgy work arround, not addressing the problem. and i dont see why you need segattach() at all. -- cinap