If a scheduler orders the timer to tick unnecessarily isn't it garbage? =)Brendan wrote: This only applies if the scheduler is garbage (round robin, 1 tick = 1 time slice). For a very simple example (without complicating things with task priorities and different scheduling algorithms), if a scheduler says "a time slice is always 50 ms", then it doesn't matter much if that's 5 ticks (at 10 ms per tick) or 500 ticks (at 100 us per tick).
More precise timing is usually for when tasks block (e.g. where the next task gets a left over fraction of a tick) and better time accounting (did this process that's constantly blocking/unblocking consume a total of 10 ms of CPU time or 9.145 ms of CPU time?) and things like "nano_delay()", and better file system timestamps.
You should only have timer IRQ (PIT, etc) when you need it, like when it's time for scheduler to switch task. What's the benefit of the extra ticks? As for accounting purposes (whether for Task Manager stats or "fairer" scheduling) you shouldn't use timer for that, use something else, like RDTSC, etc.
As for better timestamps, that's (mostly*) wallclock time, which can be handled in different ways (RDTSC, reading remaining count from timer when needed, etc).
*) Haven't really decided, but I've thought about possibly ensuring that within a system (or possibly finer grained, within a file system) the file timestamps are guaranteed unique, so there's always ordering and no two files ever have the same timestamp. Not sure though..
That is quite interesting. I'm aware that tilde has been around here a long time (I've read pretty much all of the theory forum posts), and do mostly disagree with him on most topics, but that specific topic (detecting memory) is a bit odd... Though even in the earlier (2007) post he wants to probe, so in this case I don't really see any regression, but seems there's no progress either.Brendan wrote: No, there's something much more bizarre going on here. If you look at ~'s posts from 10 years ago (mostly starting with PS/2 keyboard and mouse driver code) it's obvious that ~ wasn't a beginner back when he joined the forums; and if you compare those old posts to more recent posts it's like he's spent 10 years without gaining any knowledge/experience (and maybe even slowly going backwards in some ways).
For one random example, here's some posts by ~ from 2007 in a topic (from someone else) about detecting memory using probing; and here's some posts by ~ from last month (2017) in a topic (created by ~) about detecting memory using probing.
At least in the first post tilde is saying he wants to only support 64-bit, at which point isn't it guaranteed that either BIOS E820 is supported or UEFI is supported? Why would anyone want to probe at that point? The fact is that you have to rely on the BIOS/UEFI to a relatively large degree during boot anyway, so I don't really see much reason to not "trust" it, given that there's very little reasonable choice available.
