search for: precharging

On 25/08/2014 20:58, Christian Costa wrote: > --- > rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++--- > 1 file changed, 34 insertions(+), 3 deletions(-) > > diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml > index 500cea9..e006dbe 100644 > --- a/rnndb/memory/nvc0_pbfb.xml > +++ b/rnndb/memory/nvc0_pbfb.xml > @@ -49,23 +49,54 @@

--- rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++--- 1 file changed, 34 insertions(+), 3 deletions(-) diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml index 500cea9..e006dbe 100644 --- a/rnndb/memory/nvc0_pbfb.xml +++ b/rnndb/memory/nvc0_pbfb.xml @@ -49,23 +49,54 @@ Most bitfields are unknown. </doc> <bitfield high="7"

On 06/07/2017 11:24 AM, James Hogarth wrote: > > Mark stop with the flame baiting please. > > This is nothing systemd specific - and keep in mind /var/tmp is a > persistent temp area unlike /tmp which as it's tmpfs by default is of > course emptie don boot. I would wholeheartedly disagree. This IS something systemd specific. I have never seen init.d blow itself up over

...e. Explain then why a VM containing a given OS generally boots faster the second time on a given host than rebooting the same OS on the bare hardware running that VM host. RAM caches matter more today than they ever did, due to the vast disparity between storage access speeds in a modern system. Precharging the caches is still a good idea in 2017. > I want my hardware to boot consistently, not bomb like an Adam Sandler movie because of /symlinks/. Hyperbolic much? > I'd be willing to bet a year's salary most admins hate systemd with a passion. I think you?re basing that bet on data g...

Hello, Attached a small patch that correctly identifies the DLLoff bit for >=GF100. Marked RFC because I haven't seen any GDDR5 samples that *enable* the DLL. I'd like to verify whether the DLL should be reset when enabled. Could increase likelihood of succesfull reclock. Ben: could you do some experiments with this bit to see if GDDR5 needs some DLL reset logic? Thanks, and happy

Hi everyone, Here are new releases of bio-cgroup. Changes from the previous version are as follows: - Accurate dirty-page tracking Support migrating pages between bio-cgroups with minimum overhead, but I think such a situation is quite rare. - Fix a bug of swapcache page handling Sometimes, "bad page state" is occurred since the memory controller has temporarily changed the

Hi everyone, Here are new releases of bio-cgroup. Changes from the previous version are as follows: - Accurate dirty-page tracking Support migrating pages between bio-cgroups with minimum overhead, but I think such a situation is quite rare. - Fix a bug of swapcache page handling Sometimes, "bad page state" is occurred since the memory controller has temporarily changed the

Hi everyone, Here are new releases of bio-cgroup. Changes from the previous version are as follows: - Accurate dirty-page tracking Support migrating pages between bio-cgroups with minimum overhead, but I think such a situation is quite rare. - Fix a bug of swapcache page handling Sometimes, "bad page state" is occurred since the memory controller has temporarily changed the

The code hasn't been used since it was added to the tree, and doesn't appear to actually be usable. Signed-off-by: Christoph Hellwig <hch at lst.de> Reviewed-by: Jason Gunthorpe <jgg at mellanox.com> Acked-by: Michal Hocko <mhocko at suse.com> --- include/linux/hmm.h | 4 ++-- include/linux/ioport.h | 1 - include/linux/memremap.h | 8 --------

Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/ramcfg.h | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/bios/rammap.c | 3 ++- drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.c | 2 ++ drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c | 6 ++++-- 4 files changed, 9 insertions(+), 3 deletions(-) diff --git

In bulletpoints: - Add some support for G94 and G96 reclocking. Has been tested on literally two cards, which is hardly adequate as "full coverage". On the other hand, the changes were small enough to make me confident this might work for others as well. - Fix NV50 wait for VBLANK when no monitor is plugged in. - Voltage related inprovements for GT21x. - Slightly improve Keplers

Support transparent huge page migration to ZONE_DEVICE private memory. A new selection flag (MIGRATE_VMA_SELECT_COMPOUND) is added to request THP migration. Otherwise, THPs are split when filling in the source PFN array. A new flag (MIGRATE_PFN_COMPOUND) is added to the source PFN array to indicate a huge page can be migrated. If the device driver can allocate a huge page, it sets the

Adds reclocking for NVA0, and a whole lot of work for other cards. Had these patches collecting dust for a little, but tested them with both my NVA0, and Martin's a while back. Success not guaranteed, but should be quite a leap forward. Happy reviewing and testing. Cheers, Roy

This series adds support for transparent huge page migration to migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers. Earlier versions were posted previously [1] and [2]. The patches apply cleanly to the linux-mm 5.10.0-rc2 tree. There are a lot of other THP patches being posted. I don't think there are any semantic conflicts but there may be some merge conflicts depending on

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of Linux 5.2-rc5 and has some minor conflicts with the hmm tree that are easy to resolve. Diffstat summary: 32 files changed, 361 insertions(+), 1012 deletions(-) Git