[HN Gopher] Vramfs: Vram Based Filesystem for Linux
___________________________________________________________________
Vramfs: Vram Based Filesystem for Linux
Author : signa11
Score : 72 points
Date : 2025-03-29 17:51 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| knome wrote:
| could be a good place to sequester a swap file, similar to zram
| yjftsjthsd-h wrote:
| You _can_ , but
| https://wiki.archlinux.org/title/Swap_on_video_RAM suggests not
| doing it this way:
|
| > Warning: Multiple users have reported this to cause system
| freezes, even with the fix in #Complete system freeze under
| high memory pressure. Other GPU management processes or
| libraries may be swapped out, leading to nonrecoverable page
| faults.
|
| and in general you have to be really careful swapping to
| anything that uses a driver that could itself be swapped (which
| FUSE is especially prone to, but IIRC even ZFS and NFS did(?)
| have caveats with swap).
|
| OTOH that same page documents a way to swap to vram without
| going through userspace, so don't take this as opposition to
| the general idea:)
| 12destroyer21 wrote:
| What is the overhead on a FUSE filesystem compared to being
| implemented in the kernel? Could something like eBPF be used to
| make a faster FUSE-like filesystem driver?
| ChocolateGod wrote:
| There is considerable overhead of the user space <> kernel <>
| userspace switches, you can see similar with something like
| Wireguard if you compare the performance of its go client Vs
| the kernel driver.
|
| Some fuse drivers can avoid the overhead by letting the kernel
| know that the backing resource of a fuse filesystem can be
| handled by the kernel (e.g. for fuse based overlays FS where
| the backing storage is xfs or something), that probably isn't
| applicable here.
|
| If you're in kernel space though I don't think you'd have
| access to OpenCL so easily, you'd need to reimplement it based
| on kernel primitives.
| smw wrote:
| Tailscale tells us that, at least on some hardware,
| wireguard-go userspace performance beats the in-kernel
| implementation?
|
| https://tailscale.com/blog/more-throughput
| d3Xt3r wrote:
| If you want to avoid the overhead of FUSE, just use the phram
| kernel module:
| https://wiki.archlinux.org/title/Swap_on_video_RAM
| marbu wrote:
| > What is the overhead on a FUSE filesystem compared to being
| implemented in the kernel?
|
| The overhead is quite high, because of the additional context
| switching and copying of data between user and kernel space.
|
| > Could something like eBPF be used to make a faster FUSE-like
| filesystem driver?
|
| eBPF can't really change any of the problems I noted above. To
| improve performance one would need to change how the interface
| between kernel and user space part of FUSE filesystem works to
| make it more efficient.
|
| That said FUSE support for io_uring, which got merged recently
| in Linux 6.14, has a potential there, see:
|
| https://www.phoronix.com/news/Linux-6.14-FUSE
| hinkley wrote:
| These days is it better to use an old video card or a few PCIE
| NVME multiplexer for those same lanes?
| Tuna-Fish wrote:
| Hands down the latter. Good M.2 drives can generally get pretty
| close to the capacity of the bus, and you can fit literally a
| thousand times more stuff on 4 NVME than you can on any old
| GPU.
| dcanelhas wrote:
| On the topic of coercing bits into functioning as data storage:
| harder drive ( http://tom7.org/harder/ )
| rwmj wrote:
| Tom used nbdkit, which would have been a better choice here.
| You could probably make a VRAM plugin in a few minutes if you
| knew what the read & write calls are:
| https://gitlab.com/nbdkit/nbdkit/-/blob/6017ba21aeeb3d7ad859...
| godelski wrote:
| > harder drive
|
| Here's the direct YouTube link[0]
|
| I'd * _HIGHLY*_ recommend this video to anyone here. It is
| exactly that fun silly computer science stuff where you also
| learn a shit ton. His channel is full of this stuff.
| Don't ask why, ask why not
|
| Is essentially the motto of his channel, and it is the best.
| Leads to lots of innovations and I think we all should
| encourage more of this kind of stuff. [0]
| https://www.youtube.com/watch?v=JcJSW7Rprio
| dheera wrote:
| If you want a vramfs, why would you use GPU VRAM? CPU<->GPU copy
| speeds are not great.
|
| I have 192GB of CPU VRAM in my desktop and that was cheap to
| obtain. Absolute best build decision ever.
| LtdJorge wrote:
| What other VRAM is there?
| yjftsjthsd-h wrote:
| > I have 192GB of CPU VRAM in my desktop and that was cheap to
| obtain.
|
| How? Or what's "cheap" here? (Because I wouldn't call 192G of
| just regular RAM that's plugged into the motherboard cheap, I
| _think_ everything else is more expensive, and if there 's some
| hack here that I haven't caught I very much would like to know
| about it)
| shadowpho wrote:
| 2 GB/s is pretty crappy, that's about the burst speed of many
| nvme SSDs.
|
| Virtual disk should me more then 6 gb/s at least with ddr5.
| d3Xt3r wrote:
| Yes but bear in mind that those benchmarks were taken on an
| ancient system, with an ancient OS/kernel and FUSE:
| - OS: Ubuntu 14.04.01 LTS (64 bit) - CPU: Intel Core
| i5-2500K @ 4.0 Ghz - RAM: 8GB DDR3-1600 -
| GPU: AMD R9 290 4GB (Sapphire Tri-X)
|
| So that's an Gen 2 CPU, with DDR3 RAM and a PCIe 3.0 GPU.
|
| On a modern system, with a recent kernel+FUSE, I expect the
| results would be much better.
|
| But we also now have the phram kernel module, with which you
| can create a block device completely bypassing FUSE, so using
| phram should result in even greater performance than vramfs.
| somat wrote:
| Also all reads and writes have to go across pcie and through
| the cpu, which should be fast but you are not going to get
| vram to gpu access speeds
| Dwedit wrote:
| Using something like this would keep the GPU powered on and
| unable to shut itself off.
| mjg59 wrote:
| Why? Vram has to be powered as long as you're scanning out of
| it, any competent design is going to support powering down most
| of the GPU while keeping RAM alive otherwise an idle desktop is
| going to suck way more power than necessary
| bobmcnamara wrote:
| I wonder if any GPU is powering down chips or banks like you
| can on PC.
|
| They all have MMUs right? So you could defrag all in-use
| memory to fewer refresh domains too.
| JackYoustra wrote:
| you can validate this yourself: if you have access to an
| A/H100, allocate a 30gb tensor and do nothing - you'll see
| nvidia-smi's reported wattage go up by a watt or so
| wtallis wrote:
| GPUs will drop memory clocks dynamically, with at least one
| supported clock speed that's intended to be just fast
| enough to support scanning out the framebuffer. I haven't
| seen any indication that anybody is dynamically offlining
| VRAM capacity.
| finnjohnsen2 wrote:
| using precious vram to store files is a special kind of humor.
| especially since someone actually implemented it. kudos
| ggm wrote:
| Doesn't the graphics processor of the pi double as bootstrap
| loader?
___________________________________________________________________
(page generated 2025-03-29 23:00 UTC)