profile
viewpoint

koute/bytehound 2478

A memory profiler for Linux.

housleyjk/ws-rs 1236

Lightweight, event-driven WebSockets for Rust.

koute/cargo-web 1059

A Cargo subcommand for the client-side Web

koute/libretro-backend 41

Libretro API bindings for Rust

koute/libretro-sys 5

Raw FFI bindings to the libretro API

koute/hooky 4

A convenient LD_PRELOAD hooker

koute/cargo-shim 2

A helper library for Cargo subcommands

koute/awesome-rust 1

A curated list of Rust code and resources.

issue commentparitytech/substrate

Get rid of wasm-gc

Yes but, wouldn't they be compiled in parallel?

Assuming you have enough CPU cores of course wink

Well, indeed I do, whole 32 of them. (:

Anyhow, this seems like it's something we should measure. Maybe you could also compile polkadot (so all of the runtimes get compiled) while limiting the compilation to a certain number of cores (on Linux you should be able to do this through taskset) and compare how the compile time changes assuming we have N cores?

pepyakin

comment created time in a day

issue commentparitytech/substrate

Get rid of wasm-gc

Hmm.... indeed, although extra 40s doesn't seem that bad considering how long everything else takes to build.

The problem is that it's 40 seconds for one runtime. In polkadot we have 4 ༼ ༎ຶ ෴ ༎ຶ༽

Yes but, wouldn't they be compiled in parallel?

pepyakin

comment created time in a day

issue commentparitytech/substrate

Get rid of wasm-gc

I don't get it. AFAIK wasm builder builds the runtime with lto in release profile already. How to do you see those differences with only lto enabled:

Just guessing - probably because of the extra codegen-units=1, and also AFAIK by default lto runs in thinlto mode, doesn't it? (So it'd be different than lto=fat.)

The build time metric is a bit daunting.

Hmm.... indeed, although extra 40s doesn't seem that bad considering how long everything else takes to build.

Maybe we should have separate cargo profiles for a proper release build and a "development" release build?

pepyakin

comment created time in a day

create barnchkoute/substrate

branch : master_unsubscribe_on_drop_prototype

created branch time in a day

pull request commentparitytech/substrate

#10576: generic utility to unsubscribe from broadcast upon drop of the rx-side.

Just a note for the future: I see that you took a significant chunk of code essentially unchanged from one file and split it into multiple files (e.g. tests.rs or keys.rs). It would be significantly easier to review if that was done in a separate commit instead of being also mixed with actual code changes. Right now we basically have a diff here where two files are 100% deleted, and a bunch of files which are 100% new, and when reviewing one has to manually diff the changes between with their eyes them instead of letting the tool do that automatically.

RGafiyatullin

comment created time in a day

push eventkoute/substrate

Alexander Theißen

commit sha edaf25f99a86011c3249125274e8889b06f7adb8

Emit `ContractReverted` error when revert flag is set (#10481) * Emit `ContractReverted` error when revert flag is set * `is_success()` -> `did_revert()`

view details

Bastian Köcher

commit sha 31cc6a535cdb019763f82f8f53342ffa077fdfc6

sp-version: Add some more docs. (#10486) * sp-version: Add some more docs. * Apply suggestions from code review Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com> * Update lib.rs Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>

view details

Bastian Köcher

commit sha 027368fe34e9a57ead752d4f900db6b5f85352e6

Fix link to grafana dashboard (#10492)

view details

David

commit sha 50ab759f7a3194173ce8da0937ec2d888dee10e0

Prepare `sp-runtime` for publication (#10451) * Bump versions of sp-core and dependencies to v4.0.0 * Update references from `4.0.0-dev` –> `4.0.0` * Funny whitespace * Funny whitespace 2 * Prepare `sp-runtime` for publication

view details

dependabot[bot]

commit sha 76f6078825dc1641ef134d71ab7443b552d71273

Bump parking_lot from 0.11.1 to 0.11.2 (#10335) Bumps [parking_lot](https://github.com/Amanieu/parking_lot) from 0.11.1 to 0.11.2. - [Release notes](https://github.com/Amanieu/parking_lot/releases) - [Changelog](https://github.com/Amanieu/parking_lot/blob/master/CHANGELOG.md) - [Commits](https://github.com/Amanieu/parking_lot/compare/0.11.1...0.11.2) --- updated-dependencies: - dependency-name: parking_lot dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

Guillaume Thiolliere

commit sha 1306573829700eb5912e342e4372a3735a0b0679

Deny warning when building doc (#10387) * deny warning * add new job * fix doc * fmt

view details

dharjeezy

commit sha 4db2f22446edc340374a0e16243136b7222b0d0e

Replace parameter_types with ConstU32 &c. (#10402) * remove parameter types and use const type * remove parameter types and use const type * Delete { * Delete count, * refractor for beefy, benchmarking, child bounties, and collective pallets * refractor for pallet contracts * refractor for elections * refractor for more pallets * fix CI issues * fix CI issues * fix CI issues * fix CI issues * remove warning to fix CI issue * remove warning to fix CI issue refractor for pallet preimage * remove warning to fix CI issue refractor for pallet proxy * remove warning to fix CI issue refractor for pallet recovery refractor for pallet randomness-collective-flip * remove warning to fix CI issue refractor for pallet scored-pool refractor for pallet scheduler refractor for pallet session * remove warning to fix CI issue refractor for pallet society, support, system, timestamp, tips * remove warning to fix CI issue refractor for pallet transaction_payment, transaction_storage, treasury, uniques, utility * remove warning to fix CI issue * cargo +nightly fmt * CI fix * more param refractor on beefy-mmr * refractor for beefy * Update frame/babe/src/mock.rs * Update frame/babe/src/mock.rs * Update frame/bounties/src/tests.rs * Update frame/tips/src/tests.rs * Delete mock.rs * Update frame/examples/basic/src/tests.rs * Apply suggestions from code review * Update frame/im-online/src/mock.rs * Update frame/im-online/src/mock.rs * Update frame/offences/benchmarking/src/mock.rs * Update frame/session/benchmarking/src/mock.rs * Update frame/support/test/tests/pallet_compatibility.rs * Update frame/support/test/tests/pallet_compatibility_instance.rs * Update frame/treasury/src/tests.rs * Update test-utils/runtime/src/lib.rs * some cleanup * fmt * remove unused Co-authored-by: Damilare <dakinlose@teamapt.com> Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>

view details

Kian Paimani

commit sha 7f68a8be62433949f04abc3ab9d98a10dab95c7d

move generics of election trait to associated types (#10475) * move generics of election trait to associated types * fix doctest

view details

Nazar Mokrynskyi

commit sha 558e6d9a302518c0035d365351f4991f6e61d96c

Async block import params (#10488) * Make `SimpleSlotWorker::block_import_params()` return function that returns a future * Simplify `SimpleSlotWorker::block_import_params()` to just async method

view details

dependabot[bot]

commit sha 2db9eccff65d4fcb3eaf085bd3ea9c6b2357428f

Bump backtrace from 0.3.61 to 0.3.63 (#10495) Bumps [backtrace](https://github.com/rust-lang/backtrace-rs) from 0.3.61 to 0.3.63. - [Release notes](https://github.com/rust-lang/backtrace-rs/releases) - [Commits](https://github.com/rust-lang/backtrace-rs/compare/0.3.61...0.3.63) --- updated-dependencies: - dependency-name: backtrace dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

sandreim

commit sha fb08d15bcbea68415dd4ee90d11556b653096f10

Add logger configuration hook (#10440) * Initial poc Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> * Make config available to logger hook Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> * fmt Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> * Fix tests Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> * fmt Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> * Add metric prefix option in sc_cli::RunCmd Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> * Remove print Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> * Review fixes Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> * fmt Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> * fix docs Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>

view details

Liu-Cheng Xu

commit sha 2a7a734c373d0b28c6c658667effd3fb8c9e35bf

Use intra doc in network-gossip (#10501) * Use intra doc in network-gossip So that we could jump to the definition easily. * cargo +nightly fmt --all

view details

dependabot[bot]

commit sha ce92e8060b179ea48f1e1b3edbe8c4d296a97e30

Bump serde from 1.0.130 to 1.0.131 (#10500) Bumps [serde](https://github.com/serde-rs/serde) from 1.0.130 to 1.0.131. - [Release notes](https://github.com/serde-rs/serde/releases) - [Commits](https://github.com/serde-rs/serde/compare/v1.0.130...v1.0.131) --- updated-dependencies: - dependency-name: serde dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

Liu-Cheng Xu

commit sha a404abd3b38bd19627c7307597c99168a4f3b7bf

Derive TypeInfo for OpaqueExtrinsic (#10504)

view details

Tomasz Drwięga

commit sha 5bd5b842d4ea520d281b1398e1f54907c9862fcd

Remove offchain workers ownership. (#10506)

view details

hamidra

commit sha efa4dfa97508b2fa3676da8fe99dbf6601fd04bf

Add ClassAccount storage to unique pallet (#9940) * add ClassAccount to uniques storage * add tests for Class and ClassAccount storage * fix format * fix description * add migration * remove extra iteration * Update frame/uniques/src/migration.rs Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> * cargo run --quiet --release --features=runtime-benchmarks --manifest-path=bin/node/cli/Cargo.toml -- benchmark --chain=dev --steps=50 --repeat=20 --pallet=pallet_uniques --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --output=./frame/uniques/src/weights.rs --template=./.maintain/frame-weight-template.hbs * fix format Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Parity Bot <admin@parity.io> Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>

view details

dependabot[bot]

commit sha 8f4facada78e51dd7a16b332c2203b30c037d4d4

Bump syn from 1.0.81 to 1.0.82 (#10505) Bumps [syn](https://github.com/dtolnay/syn) from 1.0.81 to 1.0.82. - [Release notes](https://github.com/dtolnay/syn/releases) - [Commits](https://github.com/dtolnay/syn/compare/1.0.81...1.0.82) --- updated-dependencies: - dependency-name: syn dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

dependabot[bot]

commit sha 2c1eaaae147fae546c7d1e7cd7177cbaaf196f49

Bump tokio from 1.13.0 to 1.15.0 (#10512) Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.13.0 to 1.15.0. - [Release notes](https://github.com/tokio-rs/tokio/releases) - [Commits](https://github.com/tokio-rs/tokio/compare/tokio-1.13.0...tokio-1.15.0) --- updated-dependencies: - dependency-name: tokio dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

dependabot[bot]

commit sha bd763f2809e501f561aea55eba1145bca93bd9a8

Bump ss58-registry from 1.5.0 to 1.10.0 (#10515) Bumps [ss58-registry](https://github.com/paritytech/ss58-registry) from 1.5.0 to 1.10.0. - [Release notes](https://github.com/paritytech/ss58-registry/releases) - [Changelog](https://github.com/paritytech/ss58-registry/blob/main/CHANGELOG.md) - [Commits](https://github.com/paritytech/ss58-registry/compare/v1.5.0...v1.10.0) --- updated-dependencies: - dependency-name: ss58-registry dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

dependabot[bot]

commit sha 3fef614506aed18bb14d2036e70faa42f47c2c0f

Bump bytes from 1.0.1 to 1.1.0 (#10223) Bumps [bytes](https://github.com/tokio-rs/bytes) from 1.0.1 to 1.1.0. - [Release notes](https://github.com/tokio-rs/bytes/releases) - [Changelog](https://github.com/tokio-rs/bytes/blob/master/CHANGELOG.md) - [Commits](https://github.com/tokio-rs/bytes/compare/v1.0.1...v1.1.0) --- updated-dependencies: - dependency-name: bytes dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

push time in 2 days

issue commentparitytech/substrate-telemetry

Add CPU Spec Data to Feed

Hmm... this is a good idea I think, but having only the CPU model from /proc/cpuinfo seems not enough, considering some cloud providers hide this information or even lie about the hardware. It'd be nice to also have some small, simple, standarized benchmark that'd automatically run and roughly measure how fast the machine is.

wpank

comment created time in 2 days

pull request commentbytecodealliance/wasmtime

memfd/madvise-based CoW pooling allocator

Can you share the branch and/or code to reproduce the results with this PR?

Sure. Here's the branch:

https://github.com/koute/substrate/tree/master_wasmtime_benchmarks_with_cfallin_memfd_cow

And here's how to run them to get numbers for this PR (essentially the same as described in my PR, just with an extra cargo feature):

FORCE_WASMTIME_INSTANCE_POOLING=1 rustup run nightly-2021-11-01-x86_64-unknown-linux-gnu cargo bench --features wasmtime,sc-executor-wasmtime/memfd-allocator call_empty_function_from_kusama_runtime_with_recreate_instance_on_1_threads

If you have any further questions feel free to ask! (I can also make myself available for discussion on Zulip.)

Some quick benchmarking shows that this function is quite hot in this PR. That makes sense to me because @koute your PR skips that function entirely with the reuse mechanism you've implemented.

Indeed! One of the reasons why I implemented my PR the way I did is because you have to punch through less layers of abstraction so it's easier to make it faster. (:

cfallin

comment created time in 2 days

push eventkoute/wasmtime

Jan Bujak

commit sha d0cba31626615d70815cf7e54ca66fe8f3f9d6a6

Fix compilation

view details

push time in 2 days

create barnchkoute/wasmtime

branch : main_cow_instance_reuse_with_cfallin_memfd_cow

created branch time in 2 days

pull request commentbytecodealliance/wasmtime

memfd/madvise-based CoW pooling allocator

I've hooked up your implementation to our benchmarks; here are the results:

call_empty_function

dirty_1mb_of_memory

Legend:

  • instance_pooling_memfd - this PR
  • native_instance_reuse - https://github.com/bytecodealliance/wasmtime/pull/3691
  • recreate_instance - create a fresh instance with InstanceAllocationStrategy::OnDemand strategy
  • instance_pooling_with_uffd: create a fresh instance with InstanceAllocationStrategy::Pooling strategy with uffd turned on and without this PR
  • instance_pooling_without_uffd: create a fresh instance with InstanceAllocationStrategy::Pooling strategy without uffd turned on and without this PR

And here's the comparison in raw numeric values (times are in microseconds):

call_empty_function

threads instance_pooling_with_uffd instance_pooling_without_uffd recreate_instance native_instance_reuse instance_pooling_memfd
1 41 78 80 4 27
2 63 110 114 11 43
4 76 172 188 17 66
8 123 360 439 24 89
16 286 695 1117 36 127

dirty_1mb_of_memory

threads instance_pooling_with_uffd instance_pooling_without_uffd recreate_instance native_instance_reuse instance_pooling_memfd
1 312 216 221 144 238
2 844 325 334 209 385
4 1400 526 549 306 453
8 1979 1047 1168 581 618
16 3084 1814 1954 765 840

So there's still some way to go performance-wise. (:

Thanks to Jan on Zulip (are you also @koute from #3691?) for the initial idea/inspiration!

Yes that's me. (:

cfallin

comment created time in 3 days

pull request commentbytecodealliance/wasmtime

Add copy-on-write based instance reuse mechanism

I'm a bit concerned with the need to read /proc/self/pagemap to determine whether pages are present.

This it technically optional and done entirely for performance, so it could be made allowed to fail. Even without using /proc/self/pagemap my instance reuse mechanism is faster than anything that's currently in wasmtime (in our benchmarks), however it's not always faster than what we're currently using without the /proc/self/pagemap part. (And ideally we don't want to switch to anything that's slower; we want to improve performance.)

This has some interesting permissions implications (see Documentation/vm/pagemap.txt in the Linux kernel) -- some bits need root or a process capability to see, and it seems that under some kernel versions the whole file is inaccessible except by root.

That is, AFAIK, only applicable to the lower bits, which we don't need in this case. The higher bits (which we need) should be always readable when reading our own process' pagemap.

The first-class notion of snapshotting, saving globals, etc., is interesting, and I can see how it could be useful in certain scenarios. However I think it actually mixes a few ideas which we probably want to separate and design independently: the notion of instance state, snapshotting, rewinding, etc., and the implementation-level mechanism of CoW-mapping a heap image.

If your embedding doesn't work well with the pooling instance allocator then I think we'll need to brainstorm a solution which "merges" your work here with @cfallin's on the pooling allocator, taking into account the feedback around snapshots (which I personally agree is best to separate and ideally make the copy-on-write business a simple config option of "go faster")

In my initial prototype implementation I actually tried to do this in the same vein as the current pooling allocator, but in the end decided to go with the current approach. Let me explain.

Basically we have three main requirements:

  1. Be as fast as possible. (At least as fast as what we currently use, which is the legacy_instance_reuse you see on the graphs.)
  2. Be robust. (The instantiation can not fail.)
  3. Be simple to use and maintainable. (Although we can live with this not being the case if absolutely necessary.)

One of the problems with the current pooling allocator (ignoring how it performs) is that it fails at (2) and somewhat at (3), and isn't a simple "go faster" option that you can just blindly toggle. You have to manually specify module and instance limits (and if the WASM blob changes too significantly you need to modify them), and you need to maintain a separate codepath (basically keep another separate Engines and the same Module twice) for the case when instantiation fails.

So personally I think it just makes more sense (especially for something so fundamental and low level as wasmtime) to just let the user explicitly do the pooling themselves, which is very easy to do with the approach in this PR - just preinstantiate as many instances as you want into a Vec, pop one on use, push them back when you're done, and if you run out of pooled instances you can just easily instantiate one from scratch with a single extra if.

I also considered integrating this into InstancePre directly (or into a separate type) - that is, there would be no reset, and the instances would automatically reset themselves when dropped and returned into a pool inside of the InstancePre and then automatically and transparently reused when InstancePre::instantiate would be called (so that would actually be a transparent "go faster" option), but decided that it'd be better to just let the user control the pooling themselves since it's so simple to do anyway. (And also the way how everything is stored inside of the Store and not the Instance would make that somewhat awkward, since you want to reuse both the Instance and the Store.)

Basically, in our usecase we don't really care about snapshotting at all (it's just an implementation detail to make things go fast), and all we just need is to be able to instantiate clean instances as fast as possible.

Would this be more acceptable to you if API-wise we'd make it less like it's snapshotting and more like an explicit way to pool instances?

I think these are some things we should talk through after I've put up my PR and we can do comparisons. I'm really grateful for the ton of effort you put into this and look forward to comparing the approaches in more detail!

Sounds good to me! I'll hook up your PR into our benchmarks so that we can compare the performance.

koute

comment created time in 3 days

pull request commentkoute/speedy

Add support for the `glam` crate

Published as 0.8.1.

h3r2tic

comment created time in 4 days

created tagkoute/speedy

tag0.8.1

A fast binary serialization framework

created time in 4 days

push eventkoute/speedy

Jan Bujak

commit sha a43ac2f839aa5eb2025a6ab42d2f10c2019d5c40

Fix `Reader::peek_i8`

view details

Jan Bujak

commit sha 9b6496136794d8f75b1390453f70bf6e5d89f555

Add support for `i128`/`u128`

view details

Jan Bujak

commit sha d8708e117166cfba1dddfd4233e7fee375ed3107

Bump version to 0.8.1

view details

push time in 4 days

issue closedkoute/speedy

peek_i8 calls read_u8?

At src/reader.rs:70:

    #[inline(always)]
    fn peek_i8( &mut self ) -> Result< i8, C::Error > {
        self.read_u8().map( |byte| byte as i8 )
    }

I feel like read_u8 should be peek_u8. Am I mistaken?

Also, is this maintained?

closed time in 4 days

mattfbacon

issue commentkoute/speedy

peek_i8 calls read_u8?

I feel like read_u8 should be peek_u8. Am I mistaken?

Good catch; correct! It was a copy-paste error.

Also, is this maintained?

It is. It's just what I'd call "stable", so I only make changes when I need to make changes, and otherwise I'm continuously using this crate in production myself.

mattfbacon

comment created time in 4 days

push eventkoute/speedy

Tomasz Stachowiak

commit sha cd50cc673d3842431acd8c14ceddf62c7d16da8d

Add support for the `glam` crate (#13) Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>

view details

push time in 4 days

PR merged koute/speedy

Add support for the `glam` crate

Following the pattern used for chrono, smallvec and regex, this adds support for glam.

I've included basic tests for serializing all the glam types, and tested a subset thereof in a larger app.

+291 -0

1 comment

3 changed files

h3r2tic

pr closed time in 4 days

pull request commentkoute/speedy

Add support for the `glam` crate

LGTM; thanks!

h3r2tic

comment created time in 4 days

pull request commentbytecodealliance/rustix

Export `rustix::io::proc_self`

Yep, that would definitely work! Thanks! :+1:

koute

comment created time in 4 days

pull request commentbytecodealliance/wasmtime

Add copy-on-write based instance reuse mechanism

It looks like qemu's user mode emulator is not emulating madvise properly and that's why the tests are failing on aarch64; I've just checked and on a bare metal aarch64 system they all pass.

I guess ideally we should disable them when running under qemu-user?

koute

comment created time in 4 days

push eventkoute/wasmtime

Jan Bujak

commit sha 30fc9256560f4f49e26d57bd3ddecb5490e9a811

Add another test

view details

push time in 4 days

push eventkoute/wasmtime

Jan Bujak

commit sha cea9fad524fc121696638a6becad74bad796208d

Move the extra import for tests inside of the tests' mod

view details

push time in 5 days

push eventkoute/wasmtime

Jan Bujak

commit sha b0cfa7c8f3a72df7b1960e68bcdb7455dcdf446a

Fix compilation of uffd tests

view details

push time in 5 days

push eventkoute/wasmtime

Jan Bujak

commit sha d163234148251ba980bc6a1676ec02639e3d130f

When whole range is empty return the accessible offset in `Mmap::populated_range`

view details

push time in 5 days

Pull request review commentbytecodealliance/wasmtime

Add copy-on-write based instance reuse mechanism

 impl Mmap {         Ok(())     } +    /// Returns a page-aligned offset + length pair delimiting the memory pages which+    /// are currently populated without generating any extraneous page faults.+    #[cfg(target_os = "linux")]+    fn populated_range(+        &self,+        accessible_offset: usize,+        accessible: usize,+    ) -> Result<(usize, usize)> {+        // Docs: https://www.kernel.org/doc/Documentation/vm/pagemap.txt+        use std::io::{Read, Seek};+        const PAGE_SIZE: usize = 4096;++        assert_eq!(rustix::process::page_size(), 4096);++        assert_eq!(accessible_offset % 4096, 0);+        assert_eq!(accessible % 4096, 0);++        let mut page_last_index = 0;+        let mut page_first_index = None;+        unsafe {+            let mut fp = std::fs::File::open("/proc/self/pagemap")+                .context("failed to open /proc/self/pagemap")?;

Good point.

I've made a PR to rustix here to export it: https://github.com/bytecodealliance/rustix/pull/174

koute

comment created time in 5 days

PullRequestReviewEvent
more