By: Brett (ggtgp.delete@this.yahoo.com), January 19, 2020 3:34 pm
Room: Moderated Discussions
Brett (ggtgp.delete@this.yahoo.com) on January 19, 2020 2:18 pm wrote:
> Brendan (btrotter.delete@this.gmail.com) on January 19, 2020 11:25 am wrote:
> > Hi,
> >
> > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 18, 2020 9:13 pm wrote:
> > > Brendan (btrotter.delete@this.gmail.com) on January 18, 2020 11:40 am wrote:
> > > > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 17, 2020 9:08 pm wrote:
> > > > > Brendan (btrotter.delete@this.gmail.com) on January 17, 2020 12:52 pm wrote:
> > > > >
> > > > > > The difference is when you find out that you need to deal with a low memory problem - in a well defined
> > > > > > place (as soon as you try to allocate the memory) where it's easy to control the circumstances, or "at
> > > > > > any time, almost anywhere" where you have to worry about the least convenient circumstances.
> > > > >
> > > > > So in your opinion, when ever one writes "new" or "malloc", there should be (serious) handler
> > > > > in case of OOM? Able to release some random caches and so on, if at all applicable to that
> > > > > particular software? And you consider that something everyone should spend time on?
> > > >
> > > > In my opinion; a software developer should be able to do whatever they think is sane for their software
> > >
> > > Ok, I agree with this. What I obviously don't agree with is "sane" for most software.
> > >
> > > > (which could include dropping cached data, and/or waiting until another thread finishes and
> > > > releases resources,
> > > > and/or refusing to accept additional work to ensure already accepted work succeeds,
> > >
> > > I don't really see how one is supposed to do these things without trying
> > > to allocate any new memory, except in trivial toy examples.
> >
> > Why is this hard to figure out? Don't forget that you can pre-allocate (e.g. at program
> > startup/initialization, or at compile time) to avoid allocations during error handling.
> >
> > > > and/or reporting failure
> > > > in a way that is consistent with the way all other problems are reported, and/or anything else); and a
> > > > software developer should not be prevented from doing whatever they think is sane because they're forced
> > > > to accept something that is almost never sane (either OOM killer, or SIGBUS that is unusable for most
> > > > cases, or constant monitoring that can't solve the problem due to race conditions).
> > >
> > > How exactly is getting an OOM on memory allocation so much better than getting it at some other random
> > > time via signal?
> >
> > Do you honestly expect me to believe that you don't think you can handle OOM (e.g. without
> > allocations, etc) when it happens at the most convenient place you choose, but do think you
> > can handle OOM when it happens at the least convenient place that you don't choose?
> >
> > > In typical code, most allocations probably aren't done by applications own code, but some
> > > library. For example, put some std::string or std::vector to stack and they will allocate from heap too.
> > > If there's a system wide OOM going on, how can you even expect to be able to write a log message?
> >
> > Stack is pre-allocated (and without overcommit the OS guarantees that the pre-allocated stack
> > is safe to use and you won't trigger OOM by using it), when you create an simple object (e.g.
> > std:string, std:vector) you allocate memory (not the library that contains the objects class,
> > constructor, etc) and you will (unless you intentionally broke C++) either get a reference that
> > is NULL (that you must check yourself) or a "std:bad_alloc" exception (that you must catch).
> >
> > In theory there might be a library that allocates memory itself without giving you any hope of detecting
> > that when the allocation/s fail. I have never seen this and I doubt it actually exists in practice. Anybody
> > that is too incompetent to write a usable library will not write a library that anyone will use.
> >
> > > > Yes; but even for games, "what makes sense for the game" can depend on the game. For example, maybe for
> > > > one game it makes sense to do an auto-save before changing to a different level/zone, then load everything
> > > > and pre-allocate everything for the next level/zone (while managing allocation failures), then not have
> > > > a reason to care while the player remains in that level/zone
> > > > because you know everything was already allocated
> > > > successfully; and maybe for a different game that approach
> > > > can't make sense because there are no levels/zones
> > > > (or there's multiple players or ...) and something very different is far more suitable.
> > >
> > > Yeah, sure. If things happen to be just right, then it
> > > makes sense to do X. The game will need extra buffers
> > > to load everything the level needs from disk. They will be needed right until everything is loaded, at
> > > which point the memory consumption will be the highest (add some random variation due to multithreading
> > > and the fact that the player may decide to put the console to sleep in the middle of this).
> > >
> > > You are also completely ignoring that memory fragmentation
> > > gets really bad really fast, if you are constantly
> > > running near the limit. If your normal mode of operation is doing something in response to allocation
> > > failures, you're screwed anyway. All that crazy amount of error handling for nothing (note that this is
> > > no longer about system wide OOM, but strictly what's happening inside a game on a console).
> >
> > If you're constantly running near the limit; then the user is constantly being
> > told "Sorry, you can't do that because their isn't enough memory", given that:
> >
> > a1) if the software happens to support a "deallocate unnecessary data to increase the chance
> > of success" approach, then it will reach a point where there is nothing left for the software
> > to deallocate; causing the software to fall back to some other approach.
> >
> > a2) if the software happens to support a "reduce quality of work to increase the chance
> > of success" approach (e.g. maybe switching to lower resolution textures, etc), then
> > it will reach a point where there the quality of work has reached its minimum and
> > can't be reduced; causing the software to fall back to some other approach.
>
> If I were still in games I would be doing dynamic rendering distance, so pop in
> happens closer in geometry heavy areas to keep a steady frame rate above 60.
> Also I would be going small round worlds instead of flat so that I could have flat fields with long rendering
> distances. Getting sick of jagged terrains to hide poor rendering distance and hide pop in.
> I bet both are common now, neither were done when I did console
> titles. Some titles did do pop up for distant objects, yuck.
Actually dynamic rendering distance has been around forever, I meant to say this is a feature users are not aware of, and I have seen a lot of games botch this.
If you don’t manage your CPU tasks correctly you get spikes that cause frame drop.
> This is not the 64k days, anyone that complains that 4 gigabytes is not enough
> and your app is crashing due to running out of ram is running crap software.
> You can’t stream 4gb to the video card 60 times a second, games have
> more ram than they can use, if the programmer is using his brain.
>
> Servers have the same issue, you are limited by your Ethernet and
> disk throughput and seek time, and sometimes by lack of hot data.
> Too much cold data out in ram can be as useless as more disk space, if you can’t
> access the data fast enough then the user has moved on and your ad never rendered.
>
> > b) the software can't be using a "wait until other work finishes (and frees memory) before
> > continuing" approach (possibly as a fall-back); because if it was it can't be constantly
> > running near the limit (and would be constantly waiting near the limit instead).
> >
> > c) the software can't be using a "report lack of memory in a manner consistent
> > with all other errors, save user's data, then terminate" approach (possibly
> > as a fall-back); because if it was it can only reach that limit once.
> >
> > d) the only other approach (that I can think of) is "cancel that one piece of work and
> > inform the user, so all other pieces of work can continue" (possibly as a fall-back).
> >
> > Now; if the user is constantly being told "Sorry, you can't do that because their isn't enough
> > memory"; then it must be because the user hasn't stopped using your software and hasn't dealt
> > with the problem some other way (saving work in other apps and closing those other apps to
> > increase memory available to your process without losing data, buying more RAM, ...).
> >
> > In other words; the only plausible scenario that could involve
> > "constantly running near the limit" is that the
> > user doesn't mind being told "Sorry, you can't do that because
> > their isn't enough memory" constantly (possibly
> > because they know they should be glad that they're not using a dodgy piece of shit that crashes instead).
> >
> > - Brendan
> >
>
>
> Brendan (btrotter.delete@this.gmail.com) on January 19, 2020 11:25 am wrote:
> > Hi,
> >
> > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 18, 2020 9:13 pm wrote:
> > > Brendan (btrotter.delete@this.gmail.com) on January 18, 2020 11:40 am wrote:
> > > > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 17, 2020 9:08 pm wrote:
> > > > > Brendan (btrotter.delete@this.gmail.com) on January 17, 2020 12:52 pm wrote:
> > > > >
> > > > > > The difference is when you find out that you need to deal with a low memory problem - in a well defined
> > > > > > place (as soon as you try to allocate the memory) where it's easy to control the circumstances, or "at
> > > > > > any time, almost anywhere" where you have to worry about the least convenient circumstances.
> > > > >
> > > > > So in your opinion, when ever one writes "new" or "malloc", there should be (serious) handler
> > > > > in case of OOM? Able to release some random caches and so on, if at all applicable to that
> > > > > particular software? And you consider that something everyone should spend time on?
> > > >
> > > > In my opinion; a software developer should be able to do whatever they think is sane for their software
> > >
> > > Ok, I agree with this. What I obviously don't agree with is "sane" for most software.
> > >
> > > > (which could include dropping cached data, and/or waiting until another thread finishes and
> > > > releases resources,
> > > > and/or refusing to accept additional work to ensure already accepted work succeeds,
> > >
> > > I don't really see how one is supposed to do these things without trying
> > > to allocate any new memory, except in trivial toy examples.
> >
> > Why is this hard to figure out? Don't forget that you can pre-allocate (e.g. at program
> > startup/initialization, or at compile time) to avoid allocations during error handling.
> >
> > > > and/or reporting failure
> > > > in a way that is consistent with the way all other problems are reported, and/or anything else); and a
> > > > software developer should not be prevented from doing whatever they think is sane because they're forced
> > > > to accept something that is almost never sane (either OOM killer, or SIGBUS that is unusable for most
> > > > cases, or constant monitoring that can't solve the problem due to race conditions).
> > >
> > > How exactly is getting an OOM on memory allocation so much better than getting it at some other random
> > > time via signal?
> >
> > Do you honestly expect me to believe that you don't think you can handle OOM (e.g. without
> > allocations, etc) when it happens at the most convenient place you choose, but do think you
> > can handle OOM when it happens at the least convenient place that you don't choose?
> >
> > > In typical code, most allocations probably aren't done by applications own code, but some
> > > library. For example, put some std::string or std::vector to stack and they will allocate from heap too.
> > > If there's a system wide OOM going on, how can you even expect to be able to write a log message?
> >
> > Stack is pre-allocated (and without overcommit the OS guarantees that the pre-allocated stack
> > is safe to use and you won't trigger OOM by using it), when you create an simple object (e.g.
> > std:string, std:vector) you allocate memory (not the library that contains the objects class,
> > constructor, etc) and you will (unless you intentionally broke C++) either get a reference that
> > is NULL (that you must check yourself) or a "std:bad_alloc" exception (that you must catch).
> >
> > In theory there might be a library that allocates memory itself without giving you any hope of detecting
> > that when the allocation/s fail. I have never seen this and I doubt it actually exists in practice. Anybody
> > that is too incompetent to write a usable library will not write a library that anyone will use.
> >
> > > > Yes; but even for games, "what makes sense for the game" can depend on the game. For example, maybe for
> > > > one game it makes sense to do an auto-save before changing to a different level/zone, then load everything
> > > > and pre-allocate everything for the next level/zone (while managing allocation failures), then not have
> > > > a reason to care while the player remains in that level/zone
> > > > because you know everything was already allocated
> > > > successfully; and maybe for a different game that approach
> > > > can't make sense because there are no levels/zones
> > > > (or there's multiple players or ...) and something very different is far more suitable.
> > >
> > > Yeah, sure. If things happen to be just right, then it
> > > makes sense to do X. The game will need extra buffers
> > > to load everything the level needs from disk. They will be needed right until everything is loaded, at
> > > which point the memory consumption will be the highest (add some random variation due to multithreading
> > > and the fact that the player may decide to put the console to sleep in the middle of this).
> > >
> > > You are also completely ignoring that memory fragmentation
> > > gets really bad really fast, if you are constantly
> > > running near the limit. If your normal mode of operation is doing something in response to allocation
> > > failures, you're screwed anyway. All that crazy amount of error handling for nothing (note that this is
> > > no longer about system wide OOM, but strictly what's happening inside a game on a console).
> >
> > If you're constantly running near the limit; then the user is constantly being
> > told "Sorry, you can't do that because their isn't enough memory", given that:
> >
> > a1) if the software happens to support a "deallocate unnecessary data to increase the chance
> > of success" approach, then it will reach a point where there is nothing left for the software
> > to deallocate; causing the software to fall back to some other approach.
> >
> > a2) if the software happens to support a "reduce quality of work to increase the chance
> > of success" approach (e.g. maybe switching to lower resolution textures, etc), then
> > it will reach a point where there the quality of work has reached its minimum and
> > can't be reduced; causing the software to fall back to some other approach.
>
> If I were still in games I would be doing dynamic rendering distance, so pop in
> happens closer in geometry heavy areas to keep a steady frame rate above 60.
> Also I would be going small round worlds instead of flat so that I could have flat fields with long rendering
> distances. Getting sick of jagged terrains to hide poor rendering distance and hide pop in.
> I bet both are common now, neither were done when I did console
> titles. Some titles did do pop up for distant objects, yuck.
Actually dynamic rendering distance has been around forever, I meant to say this is a feature users are not aware of, and I have seen a lot of games botch this.
If you don’t manage your CPU tasks correctly you get spikes that cause frame drop.
> This is not the 64k days, anyone that complains that 4 gigabytes is not enough
> and your app is crashing due to running out of ram is running crap software.
> You can’t stream 4gb to the video card 60 times a second, games have
> more ram than they can use, if the programmer is using his brain.
>
> Servers have the same issue, you are limited by your Ethernet and
> disk throughput and seek time, and sometimes by lack of hot data.
> Too much cold data out in ram can be as useless as more disk space, if you can’t
> access the data fast enough then the user has moved on and your ad never rendered.
>
> > b) the software can't be using a "wait until other work finishes (and frees memory) before
> > continuing" approach (possibly as a fall-back); because if it was it can't be constantly
> > running near the limit (and would be constantly waiting near the limit instead).
> >
> > c) the software can't be using a "report lack of memory in a manner consistent
> > with all other errors, save user's data, then terminate" approach (possibly
> > as a fall-back); because if it was it can only reach that limit once.
> >
> > d) the only other approach (that I can think of) is "cancel that one piece of work and
> > inform the user, so all other pieces of work can continue" (possibly as a fall-back).
> >
> > Now; if the user is constantly being told "Sorry, you can't do that because their isn't enough
> > memory"; then it must be because the user hasn't stopped using your software and hasn't dealt
> > with the problem some other way (saving work in other apps and closing those other apps to
> > increase memory available to your process without losing data, buying more RAM, ...).
> >
> > In other words; the only plausible scenario that could involve
> > "constantly running near the limit" is that the
> > user doesn't mind being told "Sorry, you can't do that because
> > their isn't enough memory" constantly (possibly
> > because they know they should be glad that they're not using a dodgy piece of shit that crashes instead).
> >
> > - Brendan
> >
>
>
Topic | Posted By | Date |
---|---|---|
Nuances related to Spinlock implementation and the Linux Scheduler | Beastian | 2020/01/03 12:46 PM |
Nuances related to Spinlock implementation and the Linux Scheduler | Montaray Jack | 2020/01/03 01:14 PM |
Nuances related to Spinlock implementation and the Linux Scheduler | Montaray Jack | 2020/01/03 01:49 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/03 07:05 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Beastian | 2020/01/04 12:03 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Malte Skarupke | 2020/01/04 12:22 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/04 01:31 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | dmcq | 2020/01/05 07:33 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | smeuletz | 2020/01/06 02:05 AM |
Do not blame others for your unfinished job | smeuletz | 2020/01/06 02:08 AM |
Where did all the experts come from? Did Linus get linked? (NT) | anon | 2020/01/06 04:27 AM |
Phoronix | Gabriele Svelto | 2020/01/06 05:04 AM |
Phoronix | Salvatore De Dominicis | 2020/01/06 07:59 AM |
Do not blame anyone. Please give polite, constructive criticism | Chester | 2020/01/06 09:17 AM |
Do not blame anyone. Please give polite, constructive criticism | smeuletz | 2020/01/06 10:11 AM |
Do not blame anyone. Please give polite, constructive criticism | Chester | 2020/01/06 10:54 AM |
Do not blame anyone. Please give polite, constructive criticism | smeuletz | 2020/01/06 11:33 AM |
Do not blame anyone. Please give polite, constructive criticism | Linus Torvalds | 2020/01/06 12:58 PM |
Do not blame anyone. Please give polite, constructive criticism | Gionatan Danti | 2020/01/06 01:13 PM |
Do not blame anyone. Please give polite, constructive criticism | Linus Torvalds | 2020/01/06 01:28 PM |
Do not blame anyone. Please give polite, constructive criticism | Gionatan Danti | 2020/01/06 01:52 PM |
Do not blame anyone. Please give polite, constructive criticism | John Scott | 2020/01/10 08:48 AM |
Do not blame anyone. Please give polite, constructive criticism | supernovas | 2020/01/10 10:01 AM |
Do not blame anyone. Please give polite, constructive criticism | Linus Torvalds | 2020/01/10 12:45 PM |
Do not blame anyone. Please give polite, constructive criticism | GDan | 2020/04/06 03:10 AM |
Oracle | Anon3 | 2020/04/07 06:42 AM |
Do not blame anyone. Please give polite, constructive criticism | smeuletz | 2020/01/07 04:07 AM |
Do not blame anyone. Please give polite, constructive criticism | Simon Farnsworth | 2020/01/07 01:40 PM |
Do not blame anyone. Please give polite, constructive criticism | Etienne | 2020/01/08 02:08 AM |
Do not blame anyone. Please give polite, constructive criticism | smeuletz | 2020/01/08 02:18 AM |
Do not blame anyone. Please give polite, constructive criticism | Michael S | 2020/01/08 02:56 AM |
Not deprecating irrelevant API: sched_yield() on quantum computers? | smeuletz | 2020/01/07 04:34 AM |
Do not blame anyone. Please give polite, constructive criticism | magicalgoat | 2020/01/09 05:58 PM |
Do not blame anyone. Please give polite, constructive criticism | Linus Torvalds | 2020/01/09 10:37 PM |
Do not blame anyone. Please give polite, constructive criticism | Anon3 | 2020/01/10 04:40 PM |
Do not blame anyone. Please give polite, constructive criticism | rwessel | 2020/01/06 10:04 PM |
Do not blame anyone. Please give polite, constructive criticism | Linus Torvalds | 2020/01/06 12:11 PM |
Do not blame anyone. Please give polite, constructive criticism | Gabriele Svelto | 2020/01/06 02:36 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Howard Chu | 2020/01/09 11:39 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/10 12:30 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | president ltd | 2020/01/04 02:44 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Jörn Engel | 2020/01/04 12:34 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Emil Briggs | 2020/01/04 01:13 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Jörn Engel | 2020/01/04 01:46 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/04 02:24 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/04 03:54 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Jörn Engel | 2020/01/05 10:21 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/05 12:42 PM |
FUTEX_LOCK_PI performance | Jörn Engel | 2020/01/05 02:45 PM |
FUTEX_LOCK_PI performance | Linus Torvalds | 2020/01/05 04:30 PM |
FUTEX_LOCK_PI performance | Jörn Engel | 2020/01/05 07:03 PM |
FUTEX_LOCK_PI performance | RichardC | 2020/01/06 07:11 AM |
FUTEX_LOCK_PI performance | Linus Torvalds | 2020/01/06 01:11 PM |
FUTEX_LOCK_PI performance | Gabriele Svelto | 2020/01/06 03:20 AM |
FUTEX_LOCK_PI performance | xilun | 2020/01/06 05:19 PM |
FUTEX_LOCK_PI performance | Konrad Schwarz | 2020/01/13 04:36 AM |
FUTEX_LOCK_PI performance | Gabriele Svelto | 2020/01/13 04:53 AM |
FUTEX_LOCK_PI performance | Simon Farnsworth | 2020/01/13 05:36 AM |
FUTEX_LOCK_PI performance | rwessel | 2020/01/13 06:22 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | rainstar | 2020/01/04 10:58 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Charles Ellis | 2020/01/05 04:00 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Richard | 2020/01/05 09:58 AM |
It's hard to separate | Michael S | 2020/01/05 11:17 AM |
It's hard to separate | rainstared | 2020/01/06 01:52 AM |
It's hard to separate | David Kanter | 2020/01/08 09:27 AM |
It's hard to separate | Anon | 2020/01/08 09:37 PM |
It's hard to separate | none | 2020/01/08 11:50 PM |
It's hard to separate | Anon | 2020/01/09 01:41 AM |
It's hard to separate | none | 2020/01/09 03:54 AM |
It's hard to separate | gallier2 | 2020/01/09 04:19 AM |
It's hard to separate | Anon | 2020/01/09 05:12 AM |
It's hard to separate | Adrian | 2020/01/09 05:24 AM |
It's hard to separate | gallier2 | 2020/01/09 05:58 AM |
It's hard to separate | Adrian | 2020/01/09 07:09 AM |
It's hard to separate | gallier2 | 2020/01/09 05:42 AM |
It's hard to separate | Adrian | 2020/01/09 04:41 AM |
It's hard to separate | Anon | 2020/01/09 05:24 AM |
It's hard to separate | gallier2 | 2020/01/09 06:07 AM |
It's hard to separate | David Hess | 2020/01/09 09:27 AM |
It's hard to separate | Adrian | 2020/01/09 10:15 AM |
It's hard to separate | David Hess | 2020/01/09 10:45 AM |
It's hard to separate | Anon | 2020/01/09 11:15 AM |
It's hard to separate | Adrian | 2020/01/09 11:51 AM |
It's hard to separate | Brett | 2020/01/09 01:49 PM |
Zilog Z8000 | Brett | 2020/01/10 10:53 PM |
Zilog Z8000 | David Hess | 2020/01/11 07:06 AM |
Zilog Z8000 | Adrian | 2020/01/11 07:29 AM |
Zilog Z8000 | David Hess | 2020/01/11 08:45 AM |
Zilog Z8000 | Ricardo B | 2020/01/11 08:04 PM |
Zilog Z8000 | Ronald Maas | 2020/01/12 10:47 AM |
Zilog Z8000 | Ricardo B | 2020/01/12 12:15 PM |
Zilog Z8000 | Anon | 2020/01/12 11:34 PM |
Zilog Z8000 | Jose | 2020/01/13 01:23 AM |
Zilog Z8000 | gallier2 | 2020/01/13 01:42 AM |
Zilog Z8000 | Jose | 2020/01/13 10:04 PM |
Zilog Z8000 | rwessel | 2020/01/13 10:40 PM |
Zilog Z8000 | David Hess | 2020/01/13 11:35 PM |
Zilog Z8000 | Simon Farnsworth | 2020/01/14 03:56 AM |
Zilog Z8000 | Michael S | 2020/01/14 04:09 AM |
Zilog Z8000 | Simon Farnsworth | 2020/01/14 05:06 AM |
Zilog Z8000 | David Hess | 2020/01/14 10:22 AM |
Zilog Z8000 | David Hess | 2020/01/14 10:15 AM |
Zilog Z8000 | rwessel | 2020/01/14 04:12 PM |
286 16 bit I/O | Tim McCaffrey | 2020/01/15 11:25 AM |
286 16 bit I/O | David Hess | 2020/01/15 09:17 PM |
Zilog Z8000 | Ricardo B | 2020/01/13 11:52 AM |
Zilog Z8000 | Anon | 2020/01/13 12:25 PM |
Zilog Z8000 | David Hess | 2020/01/13 06:38 PM |
Zilog Z8000 | rwessel | 2020/01/13 07:16 PM |
Zilog Z8000 | David Hess | 2020/01/13 07:47 PM |
Zilog Z8000 | someone | 2020/01/14 07:54 AM |
Zilog Z8000 | Anon | 2020/01/14 08:31 AM |
Zilog Z8000 | Ricardo B | 2020/01/14 06:29 PM |
Zilog Z8000 | Simon Farnsworth | 2020/01/15 03:26 AM |
Zilog Z8000 | Tim McCaffrey | 2020/01/15 11:27 AM |
Zilog Z8000 | Simon Farnsworth | 2020/01/15 02:32 PM |
Zilog Z8000 | Ricardo B | 2020/01/15 03:47 PM |
Zilog Z8000 | Anon | 2020/01/15 04:08 PM |
Zilog Z8000 | Ricardo B | 2020/01/15 05:16 PM |
Zilog Z8000 | Anon | 2020/01/15 05:31 PM |
Zilog Z8000 | Ricardo B | 2020/01/15 06:46 PM |
Zilog Z8000 | Anon | 2020/01/15 07:04 PM |
Zilog Z8000 | David Hess | 2020/01/15 09:53 PM |
Zilog Z8000 | Ricardo B | 2020/01/16 07:27 PM |
Zilog Z8000 | Anon | 2020/01/16 08:33 PM |
Zilog Z8000 | Ronald Maas | 2020/01/17 12:05 AM |
Zilog Z8000 | Anon | 2020/01/17 08:15 AM |
Zilog Z8000 | Ricardo B | 2020/01/17 02:59 PM |
Zilog Z8000 | Anon | 2020/01/17 07:40 PM |
Zilog Z8000 | Ricardo B | 2020/01/18 08:42 AM |
Zilog Z8000 | gallier2 | 2020/01/19 08:02 AM |
Zilog Z8000 | David Hess | 2020/01/18 07:12 AM |
Zilog Z8000 | David Hess | 2020/01/15 09:49 PM |
Zilog Z8000 | gallier2 | 2020/01/16 12:57 AM |
Zilog Z8000 | Simon Farnsworth | 2020/01/16 02:30 AM |
IBM PC success | Etienne | 2020/01/16 06:42 AM |
Zilog Z8000 | Ricardo B | 2020/01/16 07:32 PM |
Zilog Z8000 | Brett | 2020/01/17 01:38 AM |
Zilog Z8000 | David Hess | 2020/01/18 07:28 AM |
Zilog Z8000 | David Hess | 2020/01/18 07:22 AM |
Zilog Z8000 | David Hess | 2020/01/15 09:30 PM |
Zilog Z8000 | Maxwell | 2020/01/11 09:07 AM |
Zilog Z8000 | David Hess | 2020/01/11 09:40 AM |
Zilog Z8000 | Maxwell | 2020/01/11 10:08 AM |
Zilog Z8000 | Ricardo B | 2020/01/11 08:42 PM |
8086 does NOT have those addressing modes | Devin | 2020/01/12 02:13 PM |
8086 does NOT have those addressing modes | Ricardo B | 2020/01/12 06:46 PM |
8086 does NOT have those addressing modes | Anon | 2020/01/13 05:10 AM |
8086 does NOT have those addressing modes | gallier2 | 2020/01/13 06:07 AM |
8086 does NOT have those addressing modes | Anon | 2020/01/13 07:09 AM |
8086 does NOT have those addressing modes | Ricardo B | 2020/01/13 11:48 AM |
8086 does NOT have those addressing modes | Michael S | 2020/01/13 07:40 AM |
Zilog Z8000 | Ronald Maas | 2020/01/13 09:44 AM |
Zilog Z8000 | Anon | 2020/01/13 04:32 PM |
8086 does NOT have those addressing modes | Ricardo B | 2020/01/13 11:24 AM |
8086 does NOT have those addressing modes | rwessel | 2020/01/13 03:59 PM |
8086 does NOT have those addressing modes | David Hess | 2020/01/13 07:12 PM |
8086 does NOT have those addressing modes | rwessel | 2020/01/13 07:28 PM |
8086 does NOT have those addressing modes | David Hess | 2020/01/13 07:51 PM |
8086 does NOT have those addressing modes | David Hess | 2020/01/13 06:55 PM |
Zilog Z8000 | rwessel | 2020/01/11 01:26 PM |
Zilog Z8000 | Brett | 2020/01/11 03:16 PM |
Zilog Z8000 | rwessel | 2020/01/11 08:20 PM |
Zilog Z8000 | Brett | 2020/01/12 01:02 PM |
Zilog Z8000 | rwessel | 2020/01/12 10:06 PM |
Zilog Z8000 | Brett | 2020/01/12 11:02 PM |
Zilog Z8000 | James | 2020/01/13 06:12 AM |
Zilog Z8000 | Adrian | 2020/01/12 12:38 AM |
PDP-11 | Michael S | 2020/01/12 02:33 AM |
Zilog Z8000 | rwessel | 2020/01/12 07:01 AM |
Zilog Z8000 | Ronald Maas | 2020/01/12 11:03 AM |
Zilog Z8000 | Konrad Schwarz | 2020/01/13 04:49 AM |
Zilog Z8000 | Adrian | 2020/01/14 12:38 AM |
Zilog Z8000 | konrad.schwarz | 2020/01/15 05:50 AM |
Zilog Z8000 | Adrian | 2020/01/15 11:24 PM |
It's hard to separate | David Hess | 2020/01/11 07:08 AM |
It's hard to separate | David Hess | 2020/01/11 07:11 AM |
It's hard to separate | Adrian | 2020/01/09 12:16 PM |
It's hard to separate | David Hess | 2020/01/11 07:17 AM |
It's hard to separate | gallier2 | 2020/01/10 01:11 AM |
It's hard to separate | none | 2020/01/10 02:58 AM |
It's hard to separate | rwessel | 2020/01/09 08:00 AM |
It's hard to separate | David Hess | 2020/01/09 09:10 AM |
It's hard to separate | rwessel | 2020/01/09 09:51 AM |
It's hard to separate | Adrian | 2020/01/08 11:58 PM |
It's hard to separate | rwessel | 2020/01/09 07:31 AM |
It's hard to separate | Adrian | 2020/01/09 07:44 AM |
It's hard to separate | David Hess | 2020/01/09 09:37 AM |
It's hard to separate | none | 2020/01/09 10:34 AM |
Are segments so bad? | Paul A. Clayton | 2020/01/09 03:15 PM |
Yes, they are terrible (NT) | Anon | 2020/01/09 03:20 PM |
Are segments so bad? | Adrian | 2020/01/10 12:49 AM |
Are segments so bad? | Etienne | 2020/01/10 02:28 AM |
Are segments so bad? | gallier2 | 2020/01/10 02:37 AM |
Are segments so bad? | Adrian | 2020/01/10 03:19 AM |
Are segments so bad? | Adrian | 2020/01/10 04:27 AM |
Are segments so bad? | Etienne | 2020/01/10 04:41 AM |
Are segments so bad? | Adrian | 2020/01/10 03:05 AM |
Are segments so bad? | gallier2 | 2020/01/10 03:13 AM |
Are segments so bad? | Anon3 | 2020/01/10 11:37 AM |
Are segments so bad? | Adrian | 2020/01/10 11:47 AM |
Are segments so bad? | Brendan | 2020/01/11 01:43 AM |
Are segments so bad? | Anon | 2020/01/10 06:51 PM |
Are segments so bad? | Adrian | 2020/01/11 01:05 AM |
Are segments so bad? | Jukka Larja | 2020/01/11 08:20 AM |
Are segments so bad? | Brendan | 2020/01/11 10:14 AM |
Are segments so bad? | Jukka Larja | 2020/01/11 09:15 PM |
Are segments so bad? | Brendan | 2020/01/11 11:15 PM |
Are segments so bad? | Jukka Larja | 2020/01/12 04:18 AM |
Are segments so bad? | anon | 2020/01/12 12:30 PM |
Are segments so bad? | Brendan | 2020/01/12 10:19 PM |
the world sucks worse than you're aware of | Michael S | 2020/01/13 01:50 AM |
the world sucks worse than you're aware of | Brendan | 2020/01/13 03:56 AM |
the world sucks worse than you're aware of | Gabriele Svelto | 2020/01/13 04:46 AM |
Are segments so bad? | Jukka Larja | 2020/01/13 07:41 AM |
Are segments so bad? | Brendan | 2020/01/13 08:21 AM |
Are segments so bad? | Jukka Larja | 2020/01/13 09:43 AM |
Are segments so bad? | Brendan | 2020/01/13 01:02 PM |
Are segments so bad? | Anne O. Nymous | 2020/01/13 01:22 PM |
Are segments so bad? | Brendan | 2020/01/13 02:50 PM |
actor of around 200? | Michael S | 2020/01/14 03:58 AM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/14 12:50 PM |
Not overcomitting leads to more OOMs, not less | Brendan | 2020/01/14 01:40 PM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/15 03:17 AM |
Not overcomitting leads to more OOMs, not less | Anon | 2020/01/15 04:43 AM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/15 05:09 AM |
Not overcomitting leads to more OOMs, not less | Anon | 2020/01/15 05:16 AM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/15 06:58 AM |
Not overcomitting leads to more OOMs, not less | Anon | 2020/01/15 09:08 AM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/16 04:05 AM |
Not overcomitting leads to more OOMs, not less | Michael S | 2020/01/15 04:48 AM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/15 05:10 AM |
Not overcomitting leads to more OOMs, not less | Michael S | 2020/01/15 08:13 AM |
Not overcomitting leads to more OOMs, not less | Jukka Larja | 2020/01/15 08:46 AM |
Not overcomitting leads to more OOMs, not less | Jukka Larja | 2020/01/15 06:08 AM |
Thanks for the info (NT) | Gabriele Svelto | 2020/01/15 07:00 AM |
Not overcomitting leads to more OOMs, not less | Linus Torvalds | 2020/01/15 12:30 PM |
OOM killer complains | Anon | 2020/01/15 12:44 PM |
OOM killer complains | anon | 2020/01/15 04:26 PM |
Not overcomitting leads to more OOMs, not less | Brendan | 2020/01/16 07:26 AM |
Not overcomitting leads to more OOMs, not less | Linus Torvalds | 2020/01/16 10:17 AM |
Not overcomitting leads to more OOMs, not less | Linus Torvalds | 2020/01/16 10:48 AM |
Not overcomitting leads to more OOMs, not less | Doug S | 2020/01/16 03:41 PM |
Not overcomitting leads to more OOMs, not less | Doug S | 2020/01/16 03:44 PM |
Are segments so bad? | rwessel | 2020/01/13 04:11 PM |
Are segments so bad? | Jukka Larja | 2020/01/14 07:37 AM |
Are segments so bad? | Brendan | 2020/01/14 08:48 AM |
Are segments so bad? | Jukka Larja | 2020/01/14 11:13 AM |
Are segments so bad? | Brendan | 2020/01/14 02:30 PM |
Are segments so bad? | Brett | 2020/01/14 10:13 PM |
Are segments so bad? | Jukka Larja | 2020/01/15 07:04 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/15 03:35 AM |
Specifying cost of dropping pages | Paul A. Clayton | 2020/01/13 03:00 PM |
Specifying cost of dropping pages | rwessel | 2020/01/13 04:19 PM |
Specifying cost of dropping pages | Gabriele Svelto | 2020/01/15 03:23 AM |
Are segments so bad? | anon | 2020/01/14 02:15 AM |
Are segments so bad? | Brendan | 2020/01/14 06:13 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/14 12:57 PM |
Are segments so bad? | Brendan | 2020/01/14 02:58 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/15 03:33 AM |
Are segments so bad? | Anon | 2020/01/15 05:24 AM |
Are segments so bad? | Jukka Larja | 2020/01/15 06:20 AM |
Are segments so bad? | Etienne | 2020/01/15 05:56 AM |
Are segments so bad? | Jukka Larja | 2020/01/15 08:53 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/16 06:12 AM |
Are segments so bad? | Jukka Larja | 2020/01/16 10:56 AM |
Are segments so bad? | Brendan | 2020/01/15 06:20 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/15 06:56 AM |
Are segments so bad? | Brendan | 2020/01/16 07:16 AM |
Are segments so bad? | Jukka Larja | 2020/01/16 11:08 AM |
Are segments so bad? | Brendan | 2020/01/17 01:52 PM |
Are segments so bad? | Jukka Larja | 2020/01/17 10:08 PM |
Are segments so bad? | Brendan | 2020/01/18 12:40 PM |
Are segments so bad? | Jukka Larja | 2020/01/18 10:13 PM |
Are segments so bad? | Brendan | 2020/01/19 12:25 PM |
Are segments so bad? | Brett | 2020/01/19 03:18 PM |
Are segments so bad? | Brett | 2020/01/19 03:34 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/20 12:57 AM |
Are segments so bad? | Jukka Larja | 2020/01/20 05:54 AM |
Are segments so bad? | Brendan | 2020/01/20 12:43 PM |
Are segments so bad? | Jukka Larja | 2020/01/21 07:01 AM |
Are segments so bad? | Brendan | 2020/01/21 06:04 PM |
Are segments so bad? | Jukka Larja | 2020/01/22 07:30 AM |
Are segments so bad? | Brendan | 2020/01/22 03:56 PM |
Are segments so bad? | Jukka Larja | 2020/01/23 08:44 AM |
Are segments so bad? | rwessel | 2020/01/16 03:06 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/16 03:13 PM |
Are segments so bad? | Brendan | 2020/01/17 01:51 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/17 03:18 PM |
Are segments so bad? | Anon | 2020/01/17 08:01 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/20 01:06 AM |
Are segments so bad? | Brendan | 2020/01/18 03:15 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/20 12:55 AM |
Are segments so bad? | Michael S | 2020/01/20 05:30 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/20 08:02 AM |
Are segments so bad? | Jukka Larja | 2020/01/20 08:41 AM |
Are segments so bad? | Michael S | 2020/01/20 08:45 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/20 09:36 AM |
Are segments so bad? | Brendan | 2020/01/20 11:04 AM |
Are segments so bad? | Michael S | 2020/01/20 01:22 PM |
Are segments so bad? | Brendan | 2020/01/20 02:38 PM |
Are segments so bad? | Simon Farnsworth | 2020/01/20 03:40 PM |
Are segments so bad? | Anon | 2020/01/20 04:35 PM |
Are segments so bad? | Simon Farnsworth | 2020/01/20 05:30 PM |
Are segments so bad? | Michael S | 2020/01/20 05:20 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/21 05:08 AM |
Are segments so bad? | Brendan | 2020/01/21 06:07 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/22 01:53 AM |
Are segments so bad? | Brendan | 2020/01/22 04:32 AM |
Are segments so bad? | Jukka Larja | 2020/01/22 07:12 AM |
Are segments so bad? | Brendan | 2020/01/22 04:28 PM |
Are segments so bad? | Jukka Larja | 2020/01/23 07:36 AM |
Are segments so bad? | Brendan | 2020/01/24 07:27 PM |
Are segments so bad? | Jukka Larja | 2020/01/24 10:42 PM |
Are segments so bad? | Brendan | 2020/01/25 02:46 AM |
Are segments so bad? | Jukka Larja | 2020/01/25 08:29 AM |
Are segments so bad? | Brendan | 2020/01/26 11:17 PM |
Are segments so bad? | Jukka Larja | 2020/01/27 07:55 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/27 04:33 PM |
Are segments so bad? | Jukka Larja | 2020/01/28 06:28 AM |
DDS assets and MipMap chains | Montaray Jack | 2020/01/29 03:26 AM |
Are segments so bad? | gallier2 | 2020/01/27 03:58 AM |
Are segments so bad? | Jukka Larja | 2020/01/27 06:19 AM |
Are segments so bad? | Anne O. Nymous | 2020/01/25 03:23 AM |
Are segments so bad? | Anon | 2020/01/22 05:52 PM |
Are segments so bad? | Anne O. Nymous | 2020/01/23 01:24 AM |
Are segments so bad? | Anon | 2020/01/23 05:24 PM |
Are segments so bad? | Anne O. Nymous | 2020/01/24 12:43 AM |
Are segments so bad? | Anon | 2020/01/24 04:04 AM |
Are segments so bad? | Etienne | 2020/01/24 06:10 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/23 01:48 AM |
Are segments so bad? | Michael S | 2020/01/23 03:48 AM |
Are segments so bad? | Jukka Larja | 2020/01/23 07:38 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/23 01:29 PM |
Are segments so bad? | Anon | 2020/01/23 06:08 PM |
Are segments so bad? | Jukka Larja | 2020/01/24 09:51 PM |
Are segments so bad? | Anon | 2020/01/23 06:02 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/24 03:57 AM |
Are segments so bad? | Anon | 2020/01/24 04:17 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/24 09:23 AM |
Are segments so bad? | Anon | 2020/02/02 10:15 PM |
Are segments so bad? | Gabriele Svelto | 2020/02/03 01:47 AM |
Are segments so bad? | Anon | 2020/02/03 02:34 AM |
Are segments so bad? | Gabriele Svelto | 2020/02/03 05:36 AM |
Are segments so bad? | Anon3 | 2020/02/03 08:47 AM |
Are segments so bad? | Anon | 2020/02/04 05:49 PM |
Are segments so bad? | Jukka Larja | 2020/01/24 10:10 PM |
Are segments so bad? | Jukka Larja | 2020/01/17 10:26 PM |
Are segments so bad? | Anne O. Nymous | 2020/01/12 04:18 AM |
Are segments so bad? | Jukka Larja | 2020/01/12 08:41 AM |
Are segments so bad? | rwessel | 2020/01/11 01:31 PM |
Are segments so bad? | Anne O. Nymous | 2020/01/11 08:22 AM |
Are segments so bad? | Ricardo B | 2020/01/11 08:01 PM |
Are segments so bad? | Adrian | 2020/01/12 12:18 AM |
Are segments so bad? | Michael S | 2020/01/12 02:43 AM |
Are segments so bad? | Adrian | 2020/01/12 04:35 AM |
Are segments so bad? | Ricardo B | 2020/01/12 12:04 PM |
Are segments so bad? | Anon3 | 2020/01/12 05:52 PM |
Are segments so bad? | Brendan | 2020/01/12 09:58 PM |
Are segments so bad? | Paul A. Clayton | 2020/01/13 09:11 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | rainstared | 2020/01/06 01:43 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Foo_ | 2020/01/06 05:33 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | dmcq | 2020/01/06 06:03 AM |
changes in context | Carlie Coats | 2020/01/09 09:06 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | rainstar | 2020/01/09 10:16 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Montaray Jack | 2020/01/09 11:11 PM |
Suggested reading for the author | anon | 2020/01/04 11:16 PM |
Suggested reading for the author | ab | 2020/01/05 05:15 AM |
Looking at the other side (frequency scaling) | Chester | 2020/01/06 10:19 AM |
Looking at the other side (frequency scaling) | Foo_ | 2020/01/06 11:00 AM |
Why spinlocks were used | Foo_ | 2020/01/06 11:06 AM |
Why spinlocks were used | Jukka Larja | 2020/01/06 12:59 PM |
Why spinlocks were used | Simon Cooke | 2020/01/06 03:16 PM |
Why spinlocks were used | Rizzo | 2020/01/07 01:18 AM |
Looking at the other side (frequency scaling) | ab | 2020/01/07 01:14 AM |
Cross-platform code | Gian-Carlo Pascutto | 2020/01/06 08:00 AM |
Cross-platform code | Michael S | 2020/01/06 09:11 AM |
Cross-platform code | Gian-Carlo Pascutto | 2020/01/06 12:33 PM |
Cross-platform code | Michael S | 2020/01/06 01:59 PM |
Cross-platform code | Nksingh | 2020/01/07 12:09 AM |
Cross-platform code | Michael S | 2020/01/07 02:00 AM |
SRW lock implementation | Michael S | 2020/01/07 02:35 AM |
SRW lock implementation | Nksingh | 2020/01/09 02:17 PM |
broken URL in Linux source code | Michael S | 2020/01/14 01:56 AM |
broken URL in Linux source code | Travis Downs | 2020/01/14 10:14 AM |
broken URL in Linux source code | Michael S | 2020/01/14 10:48 AM |
broken URL in Linux source code | Travis Downs | 2020/01/14 04:43 PM |
SRW lock implementation - url broken | Michael S | 2020/01/14 03:07 AM |
SRW lock implementation - url broken | Travis Downs | 2020/01/14 11:06 AM |
SRW lock implementation - url broken | gpderetta | 2020/01/15 04:28 AM |
SRW lock implementation - url broken | Travis Downs | 2020/01/15 11:16 AM |
SRW lock implementation - url broken | Linus Torvalds | 2020/01/15 11:20 AM |
SRW lock implementation - url broken | Travis Downs | 2020/01/15 11:35 AM |
SRW lock implementation - url broken | Linus Torvalds | 2020/01/16 11:24 AM |
SRW lock implementation - url broken | Konrad Schwarz | 2020/02/05 10:19 AM |
SRW lock implementation - url broken | nksingh | 2020/02/05 02:42 PM |
Cross-platform code | Linus Torvalds | 2020/01/06 01:57 PM |