By: Brett (ggtgp.delete@this.yahoo.com), January 19, 2020 2: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 11:46 AM |
Nuances related to Spinlock implementation and the Linux Scheduler | Montaray Jack | 2020/01/03 12:14 PM |
Nuances related to Spinlock implementation and the Linux Scheduler | Montaray Jack | 2020/01/03 12:49 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/03 06:05 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Beastian | 2020/01/04 11:03 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Malte Skarupke | 2020/01/04 11:22 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/04 12:31 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | dmcq | 2020/01/05 06:33 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | smeuletz | 2020/01/06 01:05 AM |
Do not blame others for your unfinished job | smeuletz | 2020/01/06 01:08 AM |
Where did all the experts come from? Did Linus get linked? (NT) | anon | 2020/01/06 03:27 AM |
Phoronix | Gabriele Svelto | 2020/01/06 04:04 AM |
Phoronix | Salvatore De Dominicis | 2020/01/06 06:59 AM |
Do not blame anyone. Please give polite, constructive criticism | Chester | 2020/01/06 08:17 AM |
Do not blame anyone. Please give polite, constructive criticism | smeuletz | 2020/01/06 09:11 AM |
Do not blame anyone. Please give polite, constructive criticism | Chester | 2020/01/06 09:54 AM |
Do not blame anyone. Please give polite, constructive criticism | smeuletz | 2020/01/06 10:33 AM |
Do not blame anyone. Please give polite, constructive criticism | Linus Torvalds | 2020/01/06 11:58 AM |
Do not blame anyone. Please give polite, constructive criticism | Gionatan Danti | 2020/01/06 12:13 PM |
Do not blame anyone. Please give polite, constructive criticism | Linus Torvalds | 2020/01/06 12:28 PM |
Do not blame anyone. Please give polite, constructive criticism | Gionatan Danti | 2020/01/06 12:52 PM |
Do not blame anyone. Please give polite, constructive criticism | John Scott | 2020/01/10 07:48 AM |
Do not blame anyone. Please give polite, constructive criticism | supernovas | 2020/01/10 09:01 AM |
Do not blame anyone. Please give polite, constructive criticism | Linus Torvalds | 2020/01/10 11:45 AM |
Do not blame anyone. Please give polite, constructive criticism | GDan | 2020/04/06 02:10 AM |
Oracle | Anon3 | 2020/04/07 05:42 AM |
Do not blame anyone. Please give polite, constructive criticism | smeuletz | 2020/01/07 03:07 AM |
Do not blame anyone. Please give polite, constructive criticism | Simon Farnsworth | 2020/01/07 12:40 PM |
Do not blame anyone. Please give polite, constructive criticism | Etienne | 2020/01/08 01:08 AM |
Do not blame anyone. Please give polite, constructive criticism | smeuletz | 2020/01/08 01:18 AM |
Do not blame anyone. Please give polite, constructive criticism | Michael S | 2020/01/08 01:56 AM |
Not deprecating irrelevant API: sched_yield() on quantum computers? | smeuletz | 2020/01/07 03:34 AM |
Do not blame anyone. Please give polite, constructive criticism | magicalgoat | 2020/01/09 04:58 PM |
Do not blame anyone. Please give polite, constructive criticism | Linus Torvalds | 2020/01/09 09:37 PM |
Do not blame anyone. Please give polite, constructive criticism | Anon3 | 2020/01/10 03:40 PM |
Do not blame anyone. Please give polite, constructive criticism | rwessel | 2020/01/06 09:04 PM |
Do not blame anyone. Please give polite, constructive criticism | Linus Torvalds | 2020/01/06 11:11 AM |
Do not blame anyone. Please give polite, constructive criticism | Gabriele Svelto | 2020/01/06 01:36 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Howard Chu | 2020/01/09 10:39 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/10 11:30 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | president ltd | 2020/01/04 01:44 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Jörn Engel | 2020/01/04 11:34 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Emil Briggs | 2020/01/04 12:13 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Jörn Engel | 2020/01/04 12:46 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/04 01:24 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/04 02:54 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Jörn Engel | 2020/01/05 09:21 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Linus Torvalds | 2020/01/05 11:42 AM |
FUTEX_LOCK_PI performance | Jörn Engel | 2020/01/05 01:45 PM |
FUTEX_LOCK_PI performance | Linus Torvalds | 2020/01/05 03:30 PM |
FUTEX_LOCK_PI performance | Jörn Engel | 2020/01/05 06:03 PM |
FUTEX_LOCK_PI performance | RichardC | 2020/01/06 06:11 AM |
FUTEX_LOCK_PI performance | Linus Torvalds | 2020/01/06 12:11 PM |
FUTEX_LOCK_PI performance | Gabriele Svelto | 2020/01/06 02:20 AM |
FUTEX_LOCK_PI performance | xilun | 2020/01/06 04:19 PM |
FUTEX_LOCK_PI performance | Konrad Schwarz | 2020/01/13 03:36 AM |
FUTEX_LOCK_PI performance | Gabriele Svelto | 2020/01/13 03:53 AM |
FUTEX_LOCK_PI performance | Simon Farnsworth | 2020/01/13 04:36 AM |
FUTEX_LOCK_PI performance | rwessel | 2020/01/13 05:22 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | rainstar | 2020/01/04 09:58 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Charles Ellis | 2020/01/05 03:00 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Richard | 2020/01/05 08:58 AM |
It's hard to separate | Michael S | 2020/01/05 10:17 AM |
It's hard to separate | rainstared | 2020/01/06 12:52 AM |
It's hard to separate | David Kanter | 2020/01/08 08:27 AM |
It's hard to separate | Anon | 2020/01/08 08:37 PM |
It's hard to separate | none | 2020/01/08 10:50 PM |
It's hard to separate | Anon | 2020/01/09 12:41 AM |
It's hard to separate | none | 2020/01/09 02:54 AM |
It's hard to separate | gallier2 | 2020/01/09 03:19 AM |
It's hard to separate | Anon | 2020/01/09 04:12 AM |
It's hard to separate | Adrian | 2020/01/09 04:24 AM |
It's hard to separate | gallier2 | 2020/01/09 04:58 AM |
It's hard to separate | Adrian | 2020/01/09 06:09 AM |
It's hard to separate | gallier2 | 2020/01/09 04:42 AM |
It's hard to separate | Adrian | 2020/01/09 03:41 AM |
It's hard to separate | Anon | 2020/01/09 04:24 AM |
It's hard to separate | gallier2 | 2020/01/09 05:07 AM |
It's hard to separate | David Hess | 2020/01/09 08:27 AM |
It's hard to separate | Adrian | 2020/01/09 09:15 AM |
It's hard to separate | David Hess | 2020/01/09 09:45 AM |
It's hard to separate | Anon | 2020/01/09 10:15 AM |
It's hard to separate | Adrian | 2020/01/09 10:51 AM |
It's hard to separate | Brett | 2020/01/09 12:49 PM |
Zilog Z8000 | Brett | 2020/01/10 09:53 PM |
Zilog Z8000 | David Hess | 2020/01/11 06:06 AM |
Zilog Z8000 | Adrian | 2020/01/11 06:29 AM |
Zilog Z8000 | David Hess | 2020/01/11 07:45 AM |
Zilog Z8000 | Ricardo B | 2020/01/11 07:04 PM |
Zilog Z8000 | Ronald Maas | 2020/01/12 09:47 AM |
Zilog Z8000 | Ricardo B | 2020/01/12 11:15 AM |
Zilog Z8000 | Anon | 2020/01/12 10:34 PM |
Zilog Z8000 | Jose | 2020/01/13 12:23 AM |
Zilog Z8000 | gallier2 | 2020/01/13 12:42 AM |
Zilog Z8000 | Jose | 2020/01/13 09:04 PM |
Zilog Z8000 | rwessel | 2020/01/13 09:40 PM |
Zilog Z8000 | David Hess | 2020/01/13 10:35 PM |
Zilog Z8000 | Simon Farnsworth | 2020/01/14 02:56 AM |
Zilog Z8000 | Michael S | 2020/01/14 03:09 AM |
Zilog Z8000 | Simon Farnsworth | 2020/01/14 04:06 AM |
Zilog Z8000 | David Hess | 2020/01/14 09:22 AM |
Zilog Z8000 | David Hess | 2020/01/14 09:15 AM |
Zilog Z8000 | rwessel | 2020/01/14 03:12 PM |
286 16 bit I/O | Tim McCaffrey | 2020/01/15 10:25 AM |
286 16 bit I/O | David Hess | 2020/01/15 08:17 PM |
Zilog Z8000 | Ricardo B | 2020/01/13 10:52 AM |
Zilog Z8000 | Anon | 2020/01/13 11:25 AM |
Zilog Z8000 | David Hess | 2020/01/13 05:38 PM |
Zilog Z8000 | rwessel | 2020/01/13 06:16 PM |
Zilog Z8000 | David Hess | 2020/01/13 06:47 PM |
Zilog Z8000 | someone | 2020/01/14 06:54 AM |
Zilog Z8000 | Anon | 2020/01/14 07:31 AM |
Zilog Z8000 | Ricardo B | 2020/01/14 05:29 PM |
Zilog Z8000 | Simon Farnsworth | 2020/01/15 02:26 AM |
Zilog Z8000 | Tim McCaffrey | 2020/01/15 10:27 AM |
Zilog Z8000 | Simon Farnsworth | 2020/01/15 01:32 PM |
Zilog Z8000 | Ricardo B | 2020/01/15 02:47 PM |
Zilog Z8000 | Anon | 2020/01/15 03:08 PM |
Zilog Z8000 | Ricardo B | 2020/01/15 04:16 PM |
Zilog Z8000 | Anon | 2020/01/15 04:31 PM |
Zilog Z8000 | Ricardo B | 2020/01/15 05:46 PM |
Zilog Z8000 | Anon | 2020/01/15 06:04 PM |
Zilog Z8000 | David Hess | 2020/01/15 08:53 PM |
Zilog Z8000 | Ricardo B | 2020/01/16 06:27 PM |
Zilog Z8000 | Anon | 2020/01/16 07:33 PM |
Zilog Z8000 | Ronald Maas | 2020/01/16 11:05 PM |
Zilog Z8000 | Anon | 2020/01/17 07:15 AM |
Zilog Z8000 | Ricardo B | 2020/01/17 01:59 PM |
Zilog Z8000 | Anon | 2020/01/17 06:40 PM |
Zilog Z8000 | Ricardo B | 2020/01/18 07:42 AM |
Zilog Z8000 | gallier2 | 2020/01/19 07:02 AM |
Zilog Z8000 | David Hess | 2020/01/18 06:12 AM |
Zilog Z8000 | David Hess | 2020/01/15 08:49 PM |
Zilog Z8000 | gallier2 | 2020/01/15 11:57 PM |
Zilog Z8000 | Simon Farnsworth | 2020/01/16 01:30 AM |
IBM PC success | Etienne | 2020/01/16 05:42 AM |
Zilog Z8000 | Ricardo B | 2020/01/16 06:32 PM |
Zilog Z8000 | Brett | 2020/01/17 12:38 AM |
Zilog Z8000 | David Hess | 2020/01/18 06:28 AM |
Zilog Z8000 | David Hess | 2020/01/18 06:22 AM |
Zilog Z8000 | David Hess | 2020/01/15 08:30 PM |
Zilog Z8000 | Maxwell | 2020/01/11 08:07 AM |
Zilog Z8000 | David Hess | 2020/01/11 08:40 AM |
Zilog Z8000 | Maxwell | 2020/01/11 09:08 AM |
Zilog Z8000 | Ricardo B | 2020/01/11 07:42 PM |
8086 does NOT have those addressing modes | Devin | 2020/01/12 01:13 PM |
8086 does NOT have those addressing modes | Ricardo B | 2020/01/12 05:46 PM |
8086 does NOT have those addressing modes | Anon | 2020/01/13 04:10 AM |
8086 does NOT have those addressing modes | gallier2 | 2020/01/13 05:07 AM |
8086 does NOT have those addressing modes | Anon | 2020/01/13 06:09 AM |
8086 does NOT have those addressing modes | Ricardo B | 2020/01/13 10:48 AM |
8086 does NOT have those addressing modes | Michael S | 2020/01/13 06:40 AM |
Zilog Z8000 | Ronald Maas | 2020/01/13 08:44 AM |
Zilog Z8000 | Anon | 2020/01/13 03:32 PM |
8086 does NOT have those addressing modes | Ricardo B | 2020/01/13 10:24 AM |
8086 does NOT have those addressing modes | rwessel | 2020/01/13 02:59 PM |
8086 does NOT have those addressing modes | David Hess | 2020/01/13 06:12 PM |
8086 does NOT have those addressing modes | rwessel | 2020/01/13 06:28 PM |
8086 does NOT have those addressing modes | David Hess | 2020/01/13 06:51 PM |
8086 does NOT have those addressing modes | David Hess | 2020/01/13 05:55 PM |
Zilog Z8000 | rwessel | 2020/01/11 12:26 PM |
Zilog Z8000 | Brett | 2020/01/11 02:16 PM |
Zilog Z8000 | rwessel | 2020/01/11 07:20 PM |
Zilog Z8000 | Brett | 2020/01/12 12:02 PM |
Zilog Z8000 | rwessel | 2020/01/12 09:06 PM |
Zilog Z8000 | Brett | 2020/01/12 10:02 PM |
Zilog Z8000 | James | 2020/01/13 05:12 AM |
Zilog Z8000 | Adrian | 2020/01/11 11:38 PM |
PDP-11 | Michael S | 2020/01/12 01:33 AM |
Zilog Z8000 | rwessel | 2020/01/12 06:01 AM |
Zilog Z8000 | Ronald Maas | 2020/01/12 10:03 AM |
Zilog Z8000 | Konrad Schwarz | 2020/01/13 03:49 AM |
Zilog Z8000 | Adrian | 2020/01/13 11:38 PM |
Zilog Z8000 | konrad.schwarz | 2020/01/15 04:50 AM |
Zilog Z8000 | Adrian | 2020/01/15 10:24 PM |
It's hard to separate | David Hess | 2020/01/11 06:08 AM |
It's hard to separate | David Hess | 2020/01/11 06:11 AM |
It's hard to separate | Adrian | 2020/01/09 11:16 AM |
It's hard to separate | David Hess | 2020/01/11 06:17 AM |
It's hard to separate | gallier2 | 2020/01/10 12:11 AM |
It's hard to separate | none | 2020/01/10 01:58 AM |
It's hard to separate | rwessel | 2020/01/09 07:00 AM |
It's hard to separate | David Hess | 2020/01/09 08:10 AM |
It's hard to separate | rwessel | 2020/01/09 08:51 AM |
It's hard to separate | Adrian | 2020/01/08 10:58 PM |
It's hard to separate | rwessel | 2020/01/09 06:31 AM |
It's hard to separate | Adrian | 2020/01/09 06:44 AM |
It's hard to separate | David Hess | 2020/01/09 08:37 AM |
It's hard to separate | none | 2020/01/09 09:34 AM |
Are segments so bad? | Paul A. Clayton | 2020/01/09 02:15 PM |
Yes, they are terrible (NT) | Anon | 2020/01/09 02:20 PM |
Are segments so bad? | Adrian | 2020/01/09 11:49 PM |
Are segments so bad? | Etienne | 2020/01/10 01:28 AM |
Are segments so bad? | gallier2 | 2020/01/10 01:37 AM |
Are segments so bad? | Adrian | 2020/01/10 02:19 AM |
Are segments so bad? | Adrian | 2020/01/10 03:27 AM |
Are segments so bad? | Etienne | 2020/01/10 03:41 AM |
Are segments so bad? | Adrian | 2020/01/10 02:05 AM |
Are segments so bad? | gallier2 | 2020/01/10 02:13 AM |
Are segments so bad? | Anon3 | 2020/01/10 10:37 AM |
Are segments so bad? | Adrian | 2020/01/10 10:47 AM |
Are segments so bad? | Brendan | 2020/01/11 12:43 AM |
Are segments so bad? | Anon | 2020/01/10 05:51 PM |
Are segments so bad? | Adrian | 2020/01/11 12:05 AM |
Are segments so bad? | Jukka Larja | 2020/01/11 07:20 AM |
Are segments so bad? | Brendan | 2020/01/11 09:14 AM |
Are segments so bad? | Jukka Larja | 2020/01/11 08:15 PM |
Are segments so bad? | Brendan | 2020/01/11 10:15 PM |
Are segments so bad? | Jukka Larja | 2020/01/12 03:18 AM |
Are segments so bad? | anon | 2020/01/12 11:30 AM |
Are segments so bad? | Brendan | 2020/01/12 09:19 PM |
the world sucks worse than you're aware of | Michael S | 2020/01/13 12:50 AM |
the world sucks worse than you're aware of | Brendan | 2020/01/13 02:56 AM |
the world sucks worse than you're aware of | Gabriele Svelto | 2020/01/13 03:46 AM |
Are segments so bad? | Jukka Larja | 2020/01/13 06:41 AM |
Are segments so bad? | Brendan | 2020/01/13 07:21 AM |
Are segments so bad? | Jukka Larja | 2020/01/13 08:43 AM |
Are segments so bad? | Brendan | 2020/01/13 12:02 PM |
Are segments so bad? | Anne O. Nymous | 2020/01/13 12:22 PM |
Are segments so bad? | Brendan | 2020/01/13 01:50 PM |
actor of around 200? | Michael S | 2020/01/14 02:58 AM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/14 11:50 AM |
Not overcomitting leads to more OOMs, not less | Brendan | 2020/01/14 12:40 PM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/15 02:17 AM |
Not overcomitting leads to more OOMs, not less | Anon | 2020/01/15 03:43 AM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/15 04:09 AM |
Not overcomitting leads to more OOMs, not less | Anon | 2020/01/15 04:16 AM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/15 05:58 AM |
Not overcomitting leads to more OOMs, not less | Anon | 2020/01/15 08:08 AM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/16 03:05 AM |
Not overcomitting leads to more OOMs, not less | Michael S | 2020/01/15 03:48 AM |
Not overcomitting leads to more OOMs, not less | Gabriele Svelto | 2020/01/15 04:10 AM |
Not overcomitting leads to more OOMs, not less | Michael S | 2020/01/15 07:13 AM |
Not overcomitting leads to more OOMs, not less | Jukka Larja | 2020/01/15 07:46 AM |
Not overcomitting leads to more OOMs, not less | Jukka Larja | 2020/01/15 05:08 AM |
Thanks for the info (NT) | Gabriele Svelto | 2020/01/15 06:00 AM |
Not overcomitting leads to more OOMs, not less | Linus Torvalds | 2020/01/15 11:30 AM |
OOM killer complains | Anon | 2020/01/15 11:44 AM |
OOM killer complains | anon | 2020/01/15 03:26 PM |
Not overcomitting leads to more OOMs, not less | Brendan | 2020/01/16 06:26 AM |
Not overcomitting leads to more OOMs, not less | Linus Torvalds | 2020/01/16 09:17 AM |
Not overcomitting leads to more OOMs, not less | Linus Torvalds | 2020/01/16 09:48 AM |
Not overcomitting leads to more OOMs, not less | Doug S | 2020/01/16 02:41 PM |
Not overcomitting leads to more OOMs, not less | Doug S | 2020/01/16 02:44 PM |
Are segments so bad? | rwessel | 2020/01/13 03:11 PM |
Are segments so bad? | Jukka Larja | 2020/01/14 06:37 AM |
Are segments so bad? | Brendan | 2020/01/14 07:48 AM |
Are segments so bad? | Jukka Larja | 2020/01/14 10:13 AM |
Are segments so bad? | Brendan | 2020/01/14 01:30 PM |
Are segments so bad? | Brett | 2020/01/14 09:13 PM |
Are segments so bad? | Jukka Larja | 2020/01/15 06:04 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/15 02:35 AM |
Specifying cost of dropping pages | Paul A. Clayton | 2020/01/13 02:00 PM |
Specifying cost of dropping pages | rwessel | 2020/01/13 03:19 PM |
Specifying cost of dropping pages | Gabriele Svelto | 2020/01/15 02:23 AM |
Are segments so bad? | anon | 2020/01/14 01:15 AM |
Are segments so bad? | Brendan | 2020/01/14 05:13 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/14 11:57 AM |
Are segments so bad? | Brendan | 2020/01/14 01:58 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/15 02:33 AM |
Are segments so bad? | Anon | 2020/01/15 04:24 AM |
Are segments so bad? | Jukka Larja | 2020/01/15 05:20 AM |
Are segments so bad? | Etienne | 2020/01/15 04:56 AM |
Are segments so bad? | Jukka Larja | 2020/01/15 07:53 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/16 05:12 AM |
Are segments so bad? | Jukka Larja | 2020/01/16 09:56 AM |
Are segments so bad? | Brendan | 2020/01/15 05:20 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/15 05:56 AM |
Are segments so bad? | Brendan | 2020/01/16 06:16 AM |
Are segments so bad? | Jukka Larja | 2020/01/16 10:08 AM |
Are segments so bad? | Brendan | 2020/01/17 12:52 PM |
Are segments so bad? | Jukka Larja | 2020/01/17 09:08 PM |
Are segments so bad? | Brendan | 2020/01/18 11:40 AM |
Are segments so bad? | Jukka Larja | 2020/01/18 09:13 PM |
Are segments so bad? | Brendan | 2020/01/19 11:25 AM |
Are segments so bad? | Brett | 2020/01/19 02:18 PM |
Are segments so bad? | Brett | 2020/01/19 02:34 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/19 11:57 PM |
Are segments so bad? | Jukka Larja | 2020/01/20 04:54 AM |
Are segments so bad? | Brendan | 2020/01/20 11:43 AM |
Are segments so bad? | Jukka Larja | 2020/01/21 06:01 AM |
Are segments so bad? | Brendan | 2020/01/21 05:04 PM |
Are segments so bad? | Jukka Larja | 2020/01/22 06:30 AM |
Are segments so bad? | Brendan | 2020/01/22 02:56 PM |
Are segments so bad? | Jukka Larja | 2020/01/23 07:44 AM |
Are segments so bad? | rwessel | 2020/01/16 02:06 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/16 02:13 PM |
Are segments so bad? | Brendan | 2020/01/17 12:51 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/17 02:18 PM |
Are segments so bad? | Anon | 2020/01/17 07:01 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/20 12:06 AM |
Are segments so bad? | Brendan | 2020/01/18 02:15 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/19 11:55 PM |
Are segments so bad? | Michael S | 2020/01/20 04:30 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/20 07:02 AM |
Are segments so bad? | Jukka Larja | 2020/01/20 07:41 AM |
Are segments so bad? | Michael S | 2020/01/20 07:45 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/20 08:36 AM |
Are segments so bad? | Brendan | 2020/01/20 10:04 AM |
Are segments so bad? | Michael S | 2020/01/20 12:22 PM |
Are segments so bad? | Brendan | 2020/01/20 01:38 PM |
Are segments so bad? | Simon Farnsworth | 2020/01/20 02:40 PM |
Are segments so bad? | Anon | 2020/01/20 03:35 PM |
Are segments so bad? | Simon Farnsworth | 2020/01/20 04:30 PM |
Are segments so bad? | Michael S | 2020/01/20 04:20 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/21 04:08 AM |
Are segments so bad? | Brendan | 2020/01/21 05:07 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/22 12:53 AM |
Are segments so bad? | Brendan | 2020/01/22 03:32 AM |
Are segments so bad? | Jukka Larja | 2020/01/22 06:12 AM |
Are segments so bad? | Brendan | 2020/01/22 03:28 PM |
Are segments so bad? | Jukka Larja | 2020/01/23 06:36 AM |
Are segments so bad? | Brendan | 2020/01/24 06:27 PM |
Are segments so bad? | Jukka Larja | 2020/01/24 09:42 PM |
Are segments so bad? | Brendan | 2020/01/25 01:46 AM |
Are segments so bad? | Jukka Larja | 2020/01/25 07:29 AM |
Are segments so bad? | Brendan | 2020/01/26 10:17 PM |
Are segments so bad? | Jukka Larja | 2020/01/27 06:55 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/27 03:33 PM |
Are segments so bad? | Jukka Larja | 2020/01/28 05:28 AM |
DDS assets and MipMap chains | Montaray Jack | 2020/01/29 02:26 AM |
Are segments so bad? | gallier2 | 2020/01/27 02:58 AM |
Are segments so bad? | Jukka Larja | 2020/01/27 05:19 AM |
Are segments so bad? | Anne O. Nymous | 2020/01/25 02:23 AM |
Are segments so bad? | Anon | 2020/01/22 04:52 PM |
Are segments so bad? | Anne O. Nymous | 2020/01/23 12:24 AM |
Are segments so bad? | Anon | 2020/01/23 04:24 PM |
Are segments so bad? | Anne O. Nymous | 2020/01/23 11:43 PM |
Are segments so bad? | Anon | 2020/01/24 03:04 AM |
Are segments so bad? | Etienne | 2020/01/24 05:10 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/23 12:48 AM |
Are segments so bad? | Michael S | 2020/01/23 02:48 AM |
Are segments so bad? | Jukka Larja | 2020/01/23 06:38 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/23 12:29 PM |
Are segments so bad? | Anon | 2020/01/23 05:08 PM |
Are segments so bad? | Jukka Larja | 2020/01/24 08:51 PM |
Are segments so bad? | Anon | 2020/01/23 05:02 PM |
Are segments so bad? | Gabriele Svelto | 2020/01/24 02:57 AM |
Are segments so bad? | Anon | 2020/01/24 03:17 AM |
Are segments so bad? | Gabriele Svelto | 2020/01/24 08:23 AM |
Are segments so bad? | Anon | 2020/02/02 09:15 PM |
Are segments so bad? | Gabriele Svelto | 2020/02/03 12:47 AM |
Are segments so bad? | Anon | 2020/02/03 01:34 AM |
Are segments so bad? | Gabriele Svelto | 2020/02/03 04:36 AM |
Are segments so bad? | Anon3 | 2020/02/03 07:47 AM |
Are segments so bad? | Anon | 2020/02/04 04:49 PM |
Are segments so bad? | Jukka Larja | 2020/01/24 09:10 PM |
Are segments so bad? | Jukka Larja | 2020/01/17 09:26 PM |
Are segments so bad? | Anne O. Nymous | 2020/01/12 03:18 AM |
Are segments so bad? | Jukka Larja | 2020/01/12 07:41 AM |
Are segments so bad? | rwessel | 2020/01/11 12:31 PM |
Are segments so bad? | Anne O. Nymous | 2020/01/11 07:22 AM |
Are segments so bad? | Ricardo B | 2020/01/11 07:01 PM |
Are segments so bad? | Adrian | 2020/01/11 11:18 PM |
Are segments so bad? | Michael S | 2020/01/12 01:43 AM |
Are segments so bad? | Adrian | 2020/01/12 03:35 AM |
Are segments so bad? | Ricardo B | 2020/01/12 11:04 AM |
Are segments so bad? | Anon3 | 2020/01/12 04:52 PM |
Are segments so bad? | Brendan | 2020/01/12 08:58 PM |
Are segments so bad? | Paul A. Clayton | 2020/01/13 08:11 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | rainstared | 2020/01/06 12:43 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Foo_ | 2020/01/06 04:33 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | dmcq | 2020/01/06 05:03 AM |
changes in context | Carlie Coats | 2020/01/09 08:06 AM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | rainstar | 2020/01/09 09:16 PM |
No nuances, just buggy code (was: related to Spinlock implementation and the Linux Scheduler) | Montaray Jack | 2020/01/09 10:11 PM |
Suggested reading for the author | anon | 2020/01/04 10:16 PM |
Suggested reading for the author | ab | 2020/01/05 04:15 AM |
Looking at the other side (frequency scaling) | Chester | 2020/01/06 09:19 AM |
Looking at the other side (frequency scaling) | Foo_ | 2020/01/06 10:00 AM |
Why spinlocks were used | Foo_ | 2020/01/06 10:06 AM |
Why spinlocks were used | Jukka Larja | 2020/01/06 11:59 AM |
Why spinlocks were used | Simon Cooke | 2020/01/06 02:16 PM |
Why spinlocks were used | Rizzo | 2020/01/07 12:18 AM |
Looking at the other side (frequency scaling) | ab | 2020/01/07 12:14 AM |
Cross-platform code | Gian-Carlo Pascutto | 2020/01/06 07:00 AM |
Cross-platform code | Michael S | 2020/01/06 08:11 AM |
Cross-platform code | Gian-Carlo Pascutto | 2020/01/06 11:33 AM |
Cross-platform code | Michael S | 2020/01/06 12:59 PM |
Cross-platform code | Nksingh | 2020/01/06 11:09 PM |
Cross-platform code | Michael S | 2020/01/07 01:00 AM |
SRW lock implementation | Michael S | 2020/01/07 01:35 AM |
SRW lock implementation | Nksingh | 2020/01/09 01:17 PM |
broken URL in Linux source code | Michael S | 2020/01/14 12:56 AM |
broken URL in Linux source code | Travis Downs | 2020/01/14 09:14 AM |
broken URL in Linux source code | Michael S | 2020/01/14 09:48 AM |
broken URL in Linux source code | Travis Downs | 2020/01/14 03:43 PM |
SRW lock implementation - url broken | Michael S | 2020/01/14 02:07 AM |
SRW lock implementation - url broken | Travis Downs | 2020/01/14 10:06 AM |
SRW lock implementation - url broken | gpderetta | 2020/01/15 03:28 AM |
SRW lock implementation - url broken | Travis Downs | 2020/01/15 10:16 AM |
SRW lock implementation - url broken | Linus Torvalds | 2020/01/15 10:20 AM |
SRW lock implementation - url broken | Travis Downs | 2020/01/15 10:35 AM |
SRW lock implementation - url broken | Linus Torvalds | 2020/01/16 10:24 AM |
SRW lock implementation - url broken | Konrad Schwarz | 2020/02/05 09:19 AM |
SRW lock implementation - url broken | nksingh | 2020/02/05 01:42 PM |
Cross-platform code | Linus Torvalds | 2020/01/06 12:57 PM |