Closed Bug 865387 Opened 11 years ago Closed 11 years ago

[OS.File] Read-ahead flag for Linux

Categories

(Toolkit Graveyard :: OS.File, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla27

People

(Reporter: Yoric, Assigned: sankha)

References

Details

(Whiteboard: [Async][Snappy])

Attachments

(3 files, 9 obsolete files)

4.29 KB, patch
Details | Diff | Splinter Review
3.74 KB, patch
Details | Diff | Splinter Review
12.71 KB, patch
Details | Diff | Splinter Review
      No description provided.
Yoric, assuming the way we do in bug 865389 for MacOS X, we will have to use the readahead function in fcntl.h for Linux, in way defined here?

http://linux.die.net/man/2/readahead
Flags: needinfo?(dteller)
As far as I understand, we should rather use fadvise() with flag FADV_SEQUENTIAL.
Cc-ing Taras to correct me if I'm wrong.
Flags: needinfo?(dteller) → needinfo?(taras.mozilla)
However, sankha93, before proceeding, please synchronize with yzen, who has been working on the MacOS X version.
(In reply to David Rajchenbach Teller [:Yoric] from comment #2)
> As far as I understand, we should rather use fadvise() with flag
> FADV_SEQUENTIAL.
> Cc-ing Taras to correct me if I'm wrong.

correct.
Flags: needinfo?(taras.mozilla)
FYI, I ran the benchmark on linux with fadvise and FADV_SEQUENTIAL (equivalent to the one for OSX) and here are the results:

*** Reading took: 117.56 cpu sec ***
*** Reading ahead took: 88.88 cpu sec ***

It works quite well on linux :)
Flags: needinfo?(dteller)
Ahah :)
Flags: needinfo?(dteller)
Attached patch Benchmark fileSplinter Review
Attaching the benchmark file to make sure I'm doing the right thing there.
Hi, sankha93. Let me know if you are still working on it, if not I will gladly pick it up from you :)
Attached patch WIP patch (obsolete) — Splinter Review
This is WIP patch. Two tests are failing in toolkit/components/osfile/tests/mochi/test_osfile_async.xul in the read_write_all() and duration() functions with a WorkerErrorEvent.

I am not sure why it is failing in read_write_all(), because just in the previous test read_write(), the OS.File.readTo() is being tested and it passes - and readahead is used by any read operation.
Assignee: nobody → sankha93
Status: NEW → ASSIGNED
Attachment #768141 - Flags: feedback?(dteller)
Comment on attachment 768141 [details] [diff] [review]
WIP patch

Review of attachment 768141 [details] [diff] [review]:
-----------------------------------------------------------------

I probably won't have time to look at it this week.
You should try setting |OS.Shared.DEBUG = true| to get more logging information.
Attachment #768141 - Flags: feedback?(dteller)
I tested with the same patch this time setting |OS.Shared.DEBUG = true| and I got this error message from the "posix_fadvise" FFI call.

> OS Agent Error while calling agent method TypeError: expected type int32_t, got (void 0) ffi@resource://gre/modules/osfile/osfile_shared_allthreads.jsm:940

But in the docs as given in http://linux.die.net/man/2/posix_fadvise it should return int. What is wrong?
"got (void 0)" means that you passed as argument |undefined|
Attached patch patch v1 (obsolete) — Splinter Review
This patch passes all tests.
Attachment #768141 - Attachment is obsolete: true
Attachment #772830 - Flags: review?(dteller)
Comment on attachment 772830 [details] [diff] [review]
patch v1

Review of attachment 772830 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/components/osfile/osfile_async_front.jsm
@@ +73,2 @@
>   */
> +let clone = OS.Shared.clone;

Could you split this in two patches?
- one patch that handles |clone| and the changes to |options|;
- another patch that handles the actual read-ahead flag.

@@ +546,5 @@
>   * to read.
> + * @param {JSON} options Optionally, an object that may contain the
> + * following fields:
> + * - {number|null} outExecutionDuration A container for the duration of the
> + * read operation.

Let's not document this here.

@@ +549,5 @@
> + * - {number|null} outExecutionDuration A container for the duration of the
> + * read operation.
> + * - {boolean} sequential - a flag that triggers a population of the page cache
> + * with data from a file so that subsequent reads from that file would not
> + * block on disk I/O. Note: |sequential| set to true by default.

"If |true| or unspecified, inform the system that the contents of the file will be read in order. Otherwise, make no such assumption."

@@ +561,5 @@
> +    // reference to |outExecutionDuration| option if it is passed.
> +    options = clone(options, ["outExecutionDuration"]);
> +    options.sequential = true;
> +  }
> +  //throw new Error(path);

I suspect you forgot to remove this.

::: toolkit/components/osfile/osfile_shared_allthreads.jsm
@@ +193,5 @@
> +           refer(result, k, object);
> +         }
> +       }
> +       return result;
> +     };

File osfile_shared_allthreads.jsm has changed a bit. You'll probably need to pull and merge your changes.

::: toolkit/components/osfile/osfile_unix_front.jsm
@@ +86,5 @@
> +       throw_on_negative("posix_fadvise",
> +         UnixFile.posix_fadvise(this.fd, offset, count,
> +          OS.Constants.libc.POSIX_FADV_SEQUENTIAL)
> +       );
> +     };

That code will work on Linux but not on platforms that do not define posix_fadvise. You should define File.prototype._unixSequential only on platforms for which posix_fadvise is defined.

@@ +106,5 @@
>        */
>       File.prototype._read = function _read(buffer, nbytes, options) {
> +       if (options.sequential && this._unixSequential) {
> +         this._unixSequential(0, nbytes);
> +       }

Let's change the logics a bit, now that we have removed options.sequential.
Attachment #772830 - Flags: review?(dteller) → feedback+
Attachment #772830 - Attachment is obsolete: true
Attachment #794616 - Flags: review?(dteller)
Attachment #794617 - Flags: review?(dteller)
Comment on attachment 794617 [details] [diff] [review]
handles actual read-ahead (part 2)

Review of attachment 794617 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/OSFileConstants.cpp
@@ +12,5 @@
>  #if defined(XP_UNIX)
>  #include "unistd.h"
>  #include "dirent.h"
>  #include "sys/stat.h"
> +//#include <linux/fadvise.h>

Why is this commented out?

::: toolkit/components/osfile/modules/osfile_unix_front.jsm
@@ +110,5 @@
>        */
>       File.prototype._read = function _read(buffer, nbytes, options) {
> +       if (options.sequential && this._unixSequential) {
> +         this._unixSequential(0, nbytes);
> +       }

I realize that I asked yzen to do the contrary, but now that it looks like only Linux will have sequential, let's simplify a little the code:
 please inline the contents of _unixSequential here.
Attachment #794617 - Flags: review?(dteller) → feedback+
Comment on attachment 794616 [details] [diff] [review]
handles options and clone (part 1)

Review of attachment 794616 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/components/osfile/modules/osfile_async_front.jsm
@@ +98,2 @@
>   */
> +let clone = OS.Shared.clone;

Please use SharedAll.clone.

@@ +324,5 @@
>      // If |buffer| is a typed array and there is no |bytes| options, we
>      // need to extract the |byteLength| now, as it will be lost by
>      // communication
> +if (isTypedArray(buffer) && !("bytes" in options)) {
> +      // Preserve reference to option |outExecutionDuration|, if it is passed.

Nit: indentation.

@@ +360,5 @@
>    write: function write(buffer, options = {}) {
>      // If |buffer| is a typed array and there is no |bytes| options,
>      // we need to extract the |byteLength| now, as it will be lost
>      // by communication
>      if (isTypedArray(buffer) && (!options || !("bytes" in options))) {

You might was well remove the !options check.

@@ +597,5 @@
> + * - {boolean} sequential - a flag that triggers a population of the page cache
> + * with data from a file so that subsequent reads from that file would not
> + * block on disk I/O. If |true| or unspecified, inform the system that the
> + * contents of the file will be read in order. Otherwise, make no such
> + * assumption. Note: |sequential| set to true by default.

Could you re-add the @param line you have removed?
Also, please replace the final sentence with just "|true| by default."

@@ +608,5 @@
> +    // Copy |options| to avoid modifying the original object but preserve the
> +    // reference to |outExecutionDuration| option if it is passed.
> +    options = clone(options, ["outExecutionDuration"]);
> +    options.sequential = true;
> +  }

I believe that we can get rid of this change.
Attachment #794616 - Flags: review?(dteller) → feedback+
Attachment #794616 - Attachment is obsolete: true
Attachment #794658 - Flags: review?(dteller)
Attachment #794617 - Attachment is obsolete: true
Attachment #794660 - Flags: review?(dteller)
Updated the #includes to prevent Mac OSX build failures.

tbpl: https://tbpl.mozilla.org/?tree=Try&rev=077635e4a3ab
Attachment #794660 - Attachment is obsolete: true
Attachment #794660 - Flags: review?(dteller)
Attachment #795421 - Flags: review?(dteller)
Oops wrong file!
Attachment #795421 - Attachment is obsolete: true
Attachment #795421 - Flags: review?(dteller)
Attachment #795423 - Flags: review?(dteller)
Attachment #794658 - Flags: review?(dteller) → review+
Comment on attachment 795423 [details] [diff] [review]
handles actual read-ahead (part 2)

Review of attachment 795423 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thanks.
Could you make the following change? No need to ask for another review just for that change.

::: toolkit/components/osfile/modules/osfile_unix_front.jsm
@@ +94,5 @@
>       File.prototype._read = function _read(buffer, nbytes, options) {
> +      // Populate the page cache with data from a file so the subsequent reads
> +      // from that file will not block on disk I/O.
> +       if ((options.sequential || !("sequential" in options)) &&
> +            UnixFile.posix_fadvise) {

Nit: I would put the condition |UnixFile.posix_fadvise| first.
Attachment #795423 - Flags: review?(dteller) → review+
Attachment #795423 - Attachment is obsolete: true
Keywords: checkin-needed
Sankha, are you planning to finish the work on this bug?
Flags: needinfo?(sankha93)
Whiteboard: [Async][Snappy]
Updated the patch. Green on try this time.

Try: https://tbpl.mozilla.org/?tree=Try&rev=8545d8acd913
Attachment #795475 - Attachment is obsolete: true
Flags: needinfo?(sankha93)
Keywords: checkin-needed
rebased patch
Attachment #794658 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/328f4650ee57
https://hg.mozilla.org/mozilla-central/rev/30d64411e9a3
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [Async][Snappy][fixed-in-fx-team] → [Async][Snappy]
Target Milestone: --- → mozilla27
Comment on attachment 816205 [details] [diff] [review]
handles options and clone (part 1), rebased

Review of attachment 816205 [details] [diff] [review]:
-----------------------------------------------------------------

This patch introduces a bug where you cannot |file.write(buffer, {bytes: bytes})| anymore.
Should I reopen or file a new bug.

::: toolkit/components/osfile/modules/osfile_async_front.jsm
@@ +381,2 @@
>        options = clone(options, ["outExecutionDuration"]);
>        options.bytes = buffer.byteLength;

This isn't correct! This will always set |options.bytes = buffer.byteLength|, overriding whatever was in options.bytes before!

@@ -420,2 @@
>        options = clone(options, ["outExecutionDuration"]);
>        options.bytes = buffer.byteLength;

This was correct, to the extend that |options.bytes| doesn't get overridden!
Blocks: 926691
(In reply to Nils Maier [:nmaier] from comment #33)
> Comment on attachment 816205 [details] [diff] [review]
> This patch introduces a bug where you cannot |file.write(buffer, {bytes:
> bytes})| anymore.
> Should I reopen or file a new bug.
> 

Filed as bug 926691.
Blocks: 928239
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: