By: Jukka Larja (roskakori2006.delete@this.gmail.com), January 27, 2020 7:55 am
Room: Moderated Discussions
Brendan (btrotter.delete@this.gmail.com) on January 26, 2020 10:17 pm wrote:
> Jukka Larja (roskakori2006.delete@this.gmail.com) on January 25, 2020 7:29 am wrote:
> > Brendan (btrotter.delete@this.gmail.com) on January 25, 2020 1:46 am wrote:
> > > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 24, 2020 9:42 pm wrote:
> > > >
> > > > I'm not sure I understand, but if I do, I should not be able to run a program that does "malloc(15GB)"
> > > > on my system with 5 GB page file (that's not the case in case you're wondering).
> > >
> > > You shouldn't be able to "malloc(15GB)" on a system that can't increase the size of the
> > > page file up to 15+ GiB later (if/when necessary). Of course if you don't use (modify)
> > > all of the 15 GB you allocated it might never increase the size of the page file.
> >
> > Just to be extra sure (though there really wasn't any doubt really), before I wrote
> > my last comment I wrote a program that allocated 15 GBs, wrote it full of stuff and
> > exited. Commit went up by 15 GBs (at the time of allocation, it wasn't increasing gradually)
> > just as expected and page file size didn't increase, just as expected.
> >
> > If you actually use Windows with normal out-of-the box settings,
> > it is trivial to note that it doesn't work like you decribe.
>
> For default settings; you'd need to fill up your file system with normal files
> to determine how much "max. commit size" depends on "how much Windows could
> increase the page file size later if necessary". That is not as trivial.
No you don't. Just take a look at working sets of running programs and you see that they wouldn't fit in normal pagefile. It doesn't matter anyway, since I already tested it and reported the results.
> > > I'm more used to the old rule of thumb, which is "twice as much swap as you have RAM"
> > > (e.g. 64 GiB of swap on a system with 32 GiB of RAM), and your idea of "relatively large"
> > > (5 GiB vs. 64 GiB) sounds more like my idea of tiny (less than 10% of 64 GiB).
> >
> > I believe that rule of thumb hasn't been relevant for about 20 years, but I'm not
> > 100 % sure. Could have been changed as late as some Windows XP service pack.
>
> I doubt the rule of thumb was ever considered accurate for any specific case. If you assume that
> the user expects the system to cope with "RAM full of working set" (which is reasonable - more
> RAM is a waste of $$ and less RAM is a performance problem), then ideal swap size depends on the
> ratio of "working set size to memory OS committed to" which varies for different software.
I think Windows 3.0 worked by that rule and the rule then stayed in effect for far too long.
I don't think "RAM full of working set" is reasonable expectation. 90 % of time "RAM half empty" is much more reasonable, so that when there's something slightly unusual going on 10 % of the time, the computer doesn't start to lag like crazy.
> > For the usual usage patterns on laptops and desktops, large page file doesn't make sense. I'm
> > a very unusual case with hundreds of tabs open in Firefox and Chrome, couple of instant messengers
> > (each hundreds of megabytes, because of course you need a browser to make a desktop app these
> > days), Thunderbird (working set 600 MBs), LibreOffice Calc and some smaller things. All that
> > nets commit of about 16 GBs. With common usage patterns (mostly running one or two apps at a
> > time, closing the browser and all tabs after each session) you're at fraction of that.
> >
> > Then consider how small the SSDs are and it makes even less sense. For common usage patterns
> > more memory means less swap space. If user does something special, then page file will grow,
> > but it makes no sense to steal even a single gigabyte out of some 120-250 GB SSD.
>
> "Usual usage patterns" are a myth. E.g. if you ask an accountant, an aerospace engineer, an
> architect, and artist what software they use you'll get 4 very different answers. I also find
> it odd that you (a game developer) didn't include games as part of your "common" usage.
Games aren't all that memory intensive (typically. There are exceptions, just like me browser use is exceptional). Assets are mostly held in GPU memory (and if GPU doesn't have (enough) memory, then it typically doesn't have enough power to use full resolution textures anyway). Very few games require more than 8 GBs or recommend more than 16. Those numbers typically have quite a bit of air, as there's no way to know what people will have running in the background. There are actually quite a large number of people who run games on systems below minimum requirements.
According to Steam hardware survey, most common GPU memory amount is 6 GBs (20 %), more than that is less than 20 % (8 GB is about 16 %). On PS4 and Xbox One, you can use about 6 GBs, splitted in whichever way you want. If you are one of those with 500+€ GPU, you'll probably buy more RAM too. Hardware survey current has 16 GBs as most common (46 %), but just month ago it was about the same as 8 GB (now 31 %). More than 16 is about 5 %, which is about the same number (or a bit more) as GPUs with more than 8 GBs of memory.
As for "Usual usage patterns", maybe I should have emphasized more that I meant anything below certain requirements. My usage patterns are crazy compared to most people, yet I could still manage with 16 GB RAM and couple of GB page file.
> For SSD sizes, a GiB is worth about 12 cents now, so 64 GiB of "SSD space" is worth less than a single
> meal at a decent restaurant.
Sadly, people don't by SSDs by GB. I have 66 GBs free and if I want to have more, I need to buy 1 TB model and go through considerable trouble to transfer the Windows installation from old disk to new one (I can do that. Most people don't know how). When I was buying this laptop, Dell Precision somethingsomething, model with 1 TB disk wasn't available from the only consumer facing retailer that was selling these Precisions.
Go take a look at the lists of top selling laptops people are buying. You'll notice that 64, or even just 16 GB is quite a chunk of typical SSD.
> However; I still think that "tiered swap" could be significantly better economics
> (e.g. $1 of SSD space and $2 of "rotating disk" space;
No way to install rotating disk or even a second disk to most laptops, and few desktops come preconfigured in that way, so not really relevant for most of the discussion.
> > It's also pretty uncommon to need to increase page file size.
>
> I was mostly thinking about Windows' "auto-manage page file size" where it frequently increases
> page file size. Also note that (in Windows 8) I could only find "initial size + max. size"
> settings, where Windows would still increase the page file size from the initial size up to
> the max. size if you don't set the initial size equal to the max. size to prevent it.
Why would it need to frequently increase page file size? Are you still presuming all allocations must be backed by page file?
> You can resize partitions now (if you want to avoid the "backup, re-partition, reinstall/restore" option).
I'm sure you can, but it's not an operation I would do lightly.
> There's multiple reasons for multiple partitions - to enforce quotas without actually having quotas (e.g.
> to make sure "/home" can't gobble all disk space and prevent updates), for performance reasons, etc.
Yes, but that wastes space. Every single one of my nicely partitioned Linux installs ended up with some partition way too big and some other too small (typically /home being oversized and some other partitions too small after couple of upgrade cycles and accumulation of cruft). Maybe someone with more experience could have anticipated the problems. I just went with what the installers suggested.
> > If you want to backup Windows, or any OS for that matter, I'm sure there's more than one file to exclude.
> > Why would restoring old page file be a problem anyway (unless you are talking about restoring over running
> > system, which doesn't really make sense in this context, if you have any idea about how Windows works)?
>
> For restoring in abnormal situations where the OS isn't running, restoring the page file
> is a waste of time. In normal situations (whether it's "system restore" or something else)
> restoring the obsolete page file is a disaster (in addition to being a waste of time).
While system is running, you can't restore any Windows system files or registry and will have trouble with Program Files and some of the configuration files too. So complaining about pagefile, while there are probably over 100000 other files that need special handling sounds pretty useless.
If your backup is just a disk image of running system, restoring that (with some boot disk) will have Windows behave as if it has unexpectedly lost power. Pagefile doesn't cause any special trouble.
Depends on situation what sort of backup makes sense.
> > > Then there's things like RAID and whole disk encryption (do you really want "RAID-5" and encryption
> > > for your page file, just because you did want those things for normal files on "C:/"?).
> >
> > No idea what Windows does with RAID 5 page file. No idea if your C: can be RAID
> > 5 in Windows either. As for encryption, you'll probably want (all) your page
> > file(s) encrypted, if you decide system drive encryption is your thing.
>
> Windows does support RAID 5 (but not RAID 6?); and I'd expect that (as RAID
> is at a lower level than file system) your page file would also using RAID.
Does it support software RAID 5 on system disk? I couldn't install even to RAID 0 about a year ago, but it could have just been me not finding proper search terms. Hardware RAID of course is possible with appropriate driver.
> For encryption; you might want swap encrypted but not file system, or files encrypted but not swap, or you
> might want different types of encryption for different cases. My main point here is that "artificial conflation
> of file system and swap" prevents flexibility (for redundancy/RAID and encryption, and anything else).
Nothing prevents you from making a separate partition and filling it with swap file. You'll probably want to do something to Windows' "disk nearly full" spam though. Some people used to do this so they could use FAT for "swap partition" for better performance. Never saw anyone quoting any benchmarks or even saying that the system feeled snappier.
My point is that for most people, who have never even heard about a page file, separate partition is less flexible and harder to manage on the fly. When those same people decide to encrypt their system disk, it's probably a very good default to encrypt the page file too (though I think Windows encrypts page file content anyway).
-JLarja
> Jukka Larja (roskakori2006.delete@this.gmail.com) on January 25, 2020 7:29 am wrote:
> > Brendan (btrotter.delete@this.gmail.com) on January 25, 2020 1:46 am wrote:
> > > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 24, 2020 9:42 pm wrote:
> > > >
> > > > I'm not sure I understand, but if I do, I should not be able to run a program that does "malloc(15GB)"
> > > > on my system with 5 GB page file (that's not the case in case you're wondering).
> > >
> > > You shouldn't be able to "malloc(15GB)" on a system that can't increase the size of the
> > > page file up to 15+ GiB later (if/when necessary). Of course if you don't use (modify)
> > > all of the 15 GB you allocated it might never increase the size of the page file.
> >
> > Just to be extra sure (though there really wasn't any doubt really), before I wrote
> > my last comment I wrote a program that allocated 15 GBs, wrote it full of stuff and
> > exited. Commit went up by 15 GBs (at the time of allocation, it wasn't increasing gradually)
> > just as expected and page file size didn't increase, just as expected.
> >
> > If you actually use Windows with normal out-of-the box settings,
> > it is trivial to note that it doesn't work like you decribe.
>
> For default settings; you'd need to fill up your file system with normal files
> to determine how much "max. commit size" depends on "how much Windows could
> increase the page file size later if necessary". That is not as trivial.
No you don't. Just take a look at working sets of running programs and you see that they wouldn't fit in normal pagefile. It doesn't matter anyway, since I already tested it and reported the results.
> > > I'm more used to the old rule of thumb, which is "twice as much swap as you have RAM"
> > > (e.g. 64 GiB of swap on a system with 32 GiB of RAM), and your idea of "relatively large"
> > > (5 GiB vs. 64 GiB) sounds more like my idea of tiny (less than 10% of 64 GiB).
> >
> > I believe that rule of thumb hasn't been relevant for about 20 years, but I'm not
> > 100 % sure. Could have been changed as late as some Windows XP service pack.
>
> I doubt the rule of thumb was ever considered accurate for any specific case. If you assume that
> the user expects the system to cope with "RAM full of working set" (which is reasonable - more
> RAM is a waste of $$ and less RAM is a performance problem), then ideal swap size depends on the
> ratio of "working set size to memory OS committed to" which varies for different software.
I think Windows 3.0 worked by that rule and the rule then stayed in effect for far too long.
I don't think "RAM full of working set" is reasonable expectation. 90 % of time "RAM half empty" is much more reasonable, so that when there's something slightly unusual going on 10 % of the time, the computer doesn't start to lag like crazy.
> > For the usual usage patterns on laptops and desktops, large page file doesn't make sense. I'm
> > a very unusual case with hundreds of tabs open in Firefox and Chrome, couple of instant messengers
> > (each hundreds of megabytes, because of course you need a browser to make a desktop app these
> > days), Thunderbird (working set 600 MBs), LibreOffice Calc and some smaller things. All that
> > nets commit of about 16 GBs. With common usage patterns (mostly running one or two apps at a
> > time, closing the browser and all tabs after each session) you're at fraction of that.
> >
> > Then consider how small the SSDs are and it makes even less sense. For common usage patterns
> > more memory means less swap space. If user does something special, then page file will grow,
> > but it makes no sense to steal even a single gigabyte out of some 120-250 GB SSD.
>
> "Usual usage patterns" are a myth. E.g. if you ask an accountant, an aerospace engineer, an
> architect, and artist what software they use you'll get 4 very different answers. I also find
> it odd that you (a game developer) didn't include games as part of your "common" usage.
Games aren't all that memory intensive (typically. There are exceptions, just like me browser use is exceptional). Assets are mostly held in GPU memory (and if GPU doesn't have (enough) memory, then it typically doesn't have enough power to use full resolution textures anyway). Very few games require more than 8 GBs or recommend more than 16. Those numbers typically have quite a bit of air, as there's no way to know what people will have running in the background. There are actually quite a large number of people who run games on systems below minimum requirements.
According to Steam hardware survey, most common GPU memory amount is 6 GBs (20 %), more than that is less than 20 % (8 GB is about 16 %). On PS4 and Xbox One, you can use about 6 GBs, splitted in whichever way you want. If you are one of those with 500+€ GPU, you'll probably buy more RAM too. Hardware survey current has 16 GBs as most common (46 %), but just month ago it was about the same as 8 GB (now 31 %). More than 16 is about 5 %, which is about the same number (or a bit more) as GPUs with more than 8 GBs of memory.
As for "Usual usage patterns", maybe I should have emphasized more that I meant anything below certain requirements. My usage patterns are crazy compared to most people, yet I could still manage with 16 GB RAM and couple of GB page file.
> For SSD sizes, a GiB is worth about 12 cents now, so 64 GiB of "SSD space" is worth less than a single
> meal at a decent restaurant.
Sadly, people don't by SSDs by GB. I have 66 GBs free and if I want to have more, I need to buy 1 TB model and go through considerable trouble to transfer the Windows installation from old disk to new one (I can do that. Most people don't know how). When I was buying this laptop, Dell Precision somethingsomething, model with 1 TB disk wasn't available from the only consumer facing retailer that was selling these Precisions.
Go take a look at the lists of top selling laptops people are buying. You'll notice that 64, or even just 16 GB is quite a chunk of typical SSD.
> However; I still think that "tiered swap" could be significantly better economics
> (e.g. $1 of SSD space and $2 of "rotating disk" space;
No way to install rotating disk or even a second disk to most laptops, and few desktops come preconfigured in that way, so not really relevant for most of the discussion.
> > It's also pretty uncommon to need to increase page file size.
>
> I was mostly thinking about Windows' "auto-manage page file size" where it frequently increases
> page file size. Also note that (in Windows 8) I could only find "initial size + max. size"
> settings, where Windows would still increase the page file size from the initial size up to
> the max. size if you don't set the initial size equal to the max. size to prevent it.
Why would it need to frequently increase page file size? Are you still presuming all allocations must be backed by page file?
> You can resize partitions now (if you want to avoid the "backup, re-partition, reinstall/restore" option).
I'm sure you can, but it's not an operation I would do lightly.
> There's multiple reasons for multiple partitions - to enforce quotas without actually having quotas (e.g.
> to make sure "/home" can't gobble all disk space and prevent updates), for performance reasons, etc.
Yes, but that wastes space. Every single one of my nicely partitioned Linux installs ended up with some partition way too big and some other too small (typically /home being oversized and some other partitions too small after couple of upgrade cycles and accumulation of cruft). Maybe someone with more experience could have anticipated the problems. I just went with what the installers suggested.
> > If you want to backup Windows, or any OS for that matter, I'm sure there's more than one file to exclude.
> > Why would restoring old page file be a problem anyway (unless you are talking about restoring over running
> > system, which doesn't really make sense in this context, if you have any idea about how Windows works)?
>
> For restoring in abnormal situations where the OS isn't running, restoring the page file
> is a waste of time. In normal situations (whether it's "system restore" or something else)
> restoring the obsolete page file is a disaster (in addition to being a waste of time).
While system is running, you can't restore any Windows system files or registry and will have trouble with Program Files and some of the configuration files too. So complaining about pagefile, while there are probably over 100000 other files that need special handling sounds pretty useless.
If your backup is just a disk image of running system, restoring that (with some boot disk) will have Windows behave as if it has unexpectedly lost power. Pagefile doesn't cause any special trouble.
Depends on situation what sort of backup makes sense.
> > > Then there's things like RAID and whole disk encryption (do you really want "RAID-5" and encryption
> > > for your page file, just because you did want those things for normal files on "C:/"?).
> >
> > No idea what Windows does with RAID 5 page file. No idea if your C: can be RAID
> > 5 in Windows either. As for encryption, you'll probably want (all) your page
> > file(s) encrypted, if you decide system drive encryption is your thing.
>
> Windows does support RAID 5 (but not RAID 6?); and I'd expect that (as RAID
> is at a lower level than file system) your page file would also using RAID.
Does it support software RAID 5 on system disk? I couldn't install even to RAID 0 about a year ago, but it could have just been me not finding proper search terms. Hardware RAID of course is possible with appropriate driver.
> For encryption; you might want swap encrypted but not file system, or files encrypted but not swap, or you
> might want different types of encryption for different cases. My main point here is that "artificial conflation
> of file system and swap" prevents flexibility (for redundancy/RAID and encryption, and anything else).
Nothing prevents you from making a separate partition and filling it with swap file. You'll probably want to do something to Windows' "disk nearly full" spam though. Some people used to do this so they could use FAT for "swap partition" for better performance. Never saw anyone quoting any benchmarks or even saying that the system feeled snappier.
My point is that for most people, who have never even heard about a page file, separate partition is less flexible and harder to manage on the fly. When those same people decide to encrypt their system disk, it's probably a very good default to encrypt the page file too (though I think Windows encrypts page file content anyway).
-JLarja
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 |